On 4/30/07, hovhannes_tumanyan <hovhannes_tumanyan@...> wrote:
>
> Folks,
> Please, excuse my ignorance, if this was discussed earlier but did
> anyone consider the impact of URL size limitation on RESTful
> application implementation in real world?
>
> To the best of my knowledge, RFC do not limit the size of URL or GET
> query string. However, quick research on the net suggests that IE, for
> instance, can't accommodate more than 2083 characters. I'm inclined to
> believe that 2083 characters (not bytes) essentially is the limit of
> state information that can be included in RESTful request.
> In reality, the real limit is even lower due to URLencoding
> requirements.
>
> Any thoughts or comments are highly appreciated and welcomed!

More restrictive than that is the IIS path length limitation of (up
to) 260 characters.

I don't know if other web servers suffer the same limitation.

Essentially, IIS assumes that the path represents a physical file and
applies the windows MAX_PATH length (this won't affect anything after
? or # in the URI). If you nest the virtual directory deep inside the
file system, this will reduce the supported path length even further.

Regards,
Alan Dean
http://thoughtpad.net/alan-dean

http://astoria.mslivelabs.com/

..the revolution has started!


www.mourant.com
The information in this email (and any attachments) may contain privileged and
confidential information and is intended solely for the use of the individual or
organisation to whom it is addressed. The contents may not be disclosed or used
by anyone other than the addressee(s). If you are not the intended recipient,
please notify Mourant immediately at the above e-mail address or telephone +44
(0)1534 609 000 and delete all copies of the e-mail from your system.

Mourant cannot accept any responsibility for the accuracy, completeness or
timely delivery of this message as it has been transmitted over a public
network. If you suspect that the message may have been intercepted or amended,
please call the sender.

Although Mourant scans e-mail and attachments for viruses, it does not guarantee
that either are virus-free and accepts no liability for any damage sustained as
a result of viruses.

Replies to this e-mail may be monitored by Mourant Limited for business and
operational reasons.

Mourant is not liable for any views or opinions expressed by the sender where
this is a non-business e-mail.

Further information on the Mourant group of companies including their registered
offices and where relevant, details of their local regulators can be accessed
via the Mourant website www.mourant.com

LOL.  These guys tried to recruit me about a couple years ago (Pablo
Castro, in fact - mentioned on the page).  I kept telling them they
needed to put an HTTP interface on their stuff, and they just couldn't
grok it.  No, they didn't realize who I was. 8-)

On 5/1/07, Philip Ruelle <Philip.Ruelle@...> wrote:
>
> http://astoria.mslivelabs.com/
>
> ..the revolution has started!
>
>
> www.mourant.com
> The information in this email (and any attachments) may contain privileged and
confidential information and is intended solely for the use of the individual or
organisation to whom it is addressed. The contents may not be disclosed or used
by anyone other than the addressee(s). If you are not the intended recipient,
please notify Mourant immediately at the above e-mail address or telephone +44
(0)1534 609 000 and delete all copies of the e-mail from your system.
>
> Mourant cannot accept any responsibility for the accuracy, completeness or
timely delivery of this message as it has been transmitted over a public
network. If you suspect that the message may have been intercepted or amended,
please call the sender.
>
> Although Mourant scans e-mail and attachments for viruses, it does not
guarantee that either are virus-free and accepts no liability for any damage
sustained as a result of viruses.
>
> Replies to this e-mail may be monitored by Mourant Limited for business and
operational reasons.
>
> Mourant is not liable for any views or opinions expressed by the sender where
this is a non-business e-mail.
>
> Further information on the Mourant group of companies including their
registered offices and where relevant, details of their local regulators can be
accessed via the Mourant website www.mourant.com
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Philip Ruelle wrote:
> http://astoria.mslivelabs.com/

One of the primary advantages of a REST approach is that you don't
need a massive framework and tools to implement it. I think these
people are missing the point.

Hello i am new to REST, but i like the approach and want to use it in
my project.
We have tests and each test has a description. This contains the input
parameters of the test, the type of test ect. A test can be executed,
and after the test has finished you get a test report.

I think of the following REST model:

Resources: TestRecipe / TestReport

To put a test recipe:
PUT http://Roger/Tests/TestRecipe
with <testrecipe> as XML document. The URI of the test recipe is returned.
With GET http://Roger/Tests/TestRecipe you will get all available test
recipes.

The problem i have is to run a test recipe. A test recipe can be
started multiple times.
POST http://Roger/Tests/TestRecipe/TestRecipe12?cmd=run
This will start a test run and the URI of the TestReport is returned.

Within the TestReport the URI of the corresponding TestRecipe is put.
The test results can be viewed by:
GET http://Roger/Tests/TestReport/TestReport12
However should this last resource be created right after creating the
run of the test recipe? The test report is available only after the
test is ready!

Love to hear your comments!

Roger vd Kimmenade

--- In rest-discuss@yahoogroups.com, Chris Burdess <dog@...> wrote:
>
> Philip Ruelle wrote:
> > http://astoria.mslivelabs.com/
>
> One of the primary advantages of a REST approach is that you don't
> need a massive framework and tools to implement it. I think these
> people are missing the point.
>

I agree - REST and simplicity seem to go hand in hand.

For the SnapLogic project, we decided very early on to keep things as
lightweight as possible, to avoid exactly this need for a massive
tools framework to support the system.

As a result of that decision, we implemented a developer oriented,
code level interface to resources in the the system as the basic
layer. This interface provides a way to build higher level tools (like
the initial GUI), while still allowing the use of the system to define
and manipulate data resources without requiring a complicated tool
chain.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Kevin" == Kevin Christen <kevin_christen@...> writes:


     Kevin> If you use PUT, the client should PUT to the URI of the
     Kevin> test recipe.  If you want the server to create the new URI,
     Kevin> the client should POST to a a URI

You can perfectly well PUT to a new URI and create it.

- --
All the best,

Berend de Boer


PS: This email has been digitally signed if you wonder what the strange
characters are that your outdated email client displays.
PGP public key: http://www.pobox.com/~berend/berend-public-key.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFGOOPzIyuuaiRyjTYRArrjAKDwLtqm8BCwqC6dAp19A1A3fcyJDgCgic0B
xXikJj5A3CmGyaC0Tinu9hs=
=d9DQ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "rogervdkimmenade" == rogervdkimmenade  <roger.van.de.kimmenade@...>
writes:

     rogervdkimmenade> Hello i am new to REST, but i like the approach
     rogervdkimmenade> and want to use it in my project.

Good! But it doesn't look like you did :-)

As things look still pretty confusing, at least for me, I suggest you
try to specify everything in terms of only the four verbs operating on
resources.

PUT for example *replaces* or *creates* a URI. Doesn't look to me you
used it that way.

For starting a test you should use POST. But another option would be
to GET a test, which would run it and return the report. Depending on
the length of the test that might be feasible approach.

Thinks like ?cmd=run don't look REST like at all.

It would be better to POST a test id to a run queue or so.

Hopes this helps a bit.

- --
Regards,

Berend de Boer


PS: This email has been digitally signed if you wonder what the strange
characters are that your outdated email client displays.
PGP public key: http://www.pobox.com/~berend/berend-public-key.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFGOOTuIyuuaiRyjTYRAvxYAJ4gumSTsElIbWHb00IJe0sdfr24lgCfUCnP
QMccBLC+gzeKsZmVneG/1bI=
=hoWg
-----END PGP SIGNATURE-----

Well, perhaps they need massive frameworks and tools to stay employed?


> -----Original Message-----
> From: rest-discuss@yahoogroups.com
> [mailto:rest-discuss@yahoogroups.com] On Behalf Of Chris Burdess
> Sent: Wednesday, May 02, 2007 12:52 AM
> To: Philip Ruelle
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] First Tim Ewald, now the MS Data
> Access & Storage team....
>
> Philip Ruelle wrote:
> > http://astoria.mslivelabs.com/
>
> One of the primary advantages of a REST approach is that you
> don't need a massive framework and tools to implement it. I
> think these people are missing the point.
>
>
>
> Yahoo! Groups Links
>
>
>

On Wed, 2007-05-02 at 17:57 -0700, Mike Dierken wrote:
> Well, perhaps they need massive frameworks and tools to stay employed?

Perhaps, but it's unclear how "massive" this is, especially given some
of the benefits.  It looks like a maybe slightly over-engineered way to
expose resources and queries via HTTP, via XML, JSON and RDF.  Good on
them, for that.  I confess I've not really looked at it past the .DOCs
at the web site...

The things that are more worrisome to me are the use of brackets to
index resources (e.g., </customer>, </customer[42]>) rather than another
slash for hierarchy.  OTOH, I've never seen really useful benefits of
hierarchical resources.  Also, I'm not sure that '[]' are allowed in
URIs...  Obviously, they could be encoded, but it doesn't seem wise to
choose a character that needs to be {en,de}coded all the time.

Also potentially worrisome is embedding a structured query language in
the non-query-part of URIs, e.g. </customer[Active eq true]>.   Of
course, having a query language is good, but it feels "nicer" to encode
it in the query part, somehow ... though maybe I'm just getting
distracted because they use the same word "query".  I mean, the
aforementioned query *is* a distinct resource, and can be cached,
respond to methods, &c.

Has anyone delved deeper into it?

--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}

On 5/2/07, mikeyp_falco <mikeyp@...> wrote:
>
> --- In rest-discuss@yahoogroups.com, Chris Burdess <dog@...> wrote:
>  >
>  > Philip Ruelle wrote:
>  > > http://astoria.mslivelabs.com/
>  >
>  > One of the primary advantages of a REST approach is that you don't
>  > need a massive framework and tools to implement it.

You do need a massive framework and tools. It's just that those tools
are shipping and functional, instead of existing only in the minds of
PDF authors producing vaporware. We call these massive frameworks and
tools HTTP clients and servers. It is a big mistake to build new
massive frameworks on top of a massive framework if you don't need to.

Of course, now the software industry will now get to compete with a
more clueful bunch of MS HTTP products, instead of the WS-Bogus
nonsense you could immediately write off and never think about again.
The Astoria stuff may not be the prettiest, but it looks to me like it
will *actually work* without an army of consultants, which is a big
change.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

On 2 May 2007, at 09:56, rogervdkimmenade wrote:

> Within the TestReport the URI of the corresponding TestRecipe is put.
> The test results can be viewed by:
> GET http://Roger/Tests/TestReport/TestReport12

(BTW, I don't really fancy the CamelCase style URLs, but I guess
that's not as important.. and do we need to repeat 'Test' everywhere
when it's under /Test ?)


What about including the test run as a real resource? After all it
has state (running, finished, etc) and references other resources,
such as the recipe and the report.


(I'm shortening the URLs and content):

POST /TestRecipe
<testrecipe> ..

201 Created
Location: /TestRecipe/13


POST /TestRun
<testrun>
    <testrecipe xlink:href="/TestRecipe/13" />
</>

201 Created
Location: /TestRun/192


GET /TestRun/192
<testrun>
    <testrecipe xlink:href="/TestRecipe/13" />
    <status>Running</status>
    ..  (Could include data such as when it was started etc)


GET /TestRun/192
<testrun>
    <testrecipe xlink:href="/TestRecipe/13" />
    <status>Finished</status>
    <result>Failed</result>
    <report xlink:href="/TestRun/192/report" />
..


GET /TestRun/192/report
<testreport>
    ..


This means that if some other conditions have changed, you can post a
new test run using the old test recipe URI.

--
Stian Soiland, myGrid team
School of Computer Science
The University of Manchester
http://www.cs.man.ac.uk/~ssoiland/

Mark Baker wrote:
>
>
> LOL. These guys tried to recruit me about a couple years ago (Pablo
> Castro, in fact - mentioned on the page). I kept telling them they
> needed to put an HTTP interface on their stuff, and they just couldn't
> grok it. No, they didn't realize who I was. 8-)


I'm more interested to see how these ideas gets productized inside MSFT,
specifically how it works its way into sharepoint*. It segues nicely
with the current arguments around open document formats, which are as
much about server sided repositories as they are about word processors.

cheers
Bill


* and to a lesser degree, biztalk

Robert Sayre wrote:
>
>
> On 5/2/07, mikeyp_falco <mikeyp@...
> <mailto:mikeyp%40snaplogic.org>> wrote:
>>
>> --- In rest-discuss@yahoogroups.com
> <mailto:rest-discuss%40yahoogroups.com>, Chris Burdess <dog@...> wrote:
>> >
>> > Philip Ruelle wrote:
>> > > http://astoria.mslivelabs.com/ <http://astoria.mslivelabs.com/>
>> >
>> > One of the primary advantages of a REST approach is that you don't
>> > need a massive framework and tools to implement it.
>
> You do need a massive framework and tools. It's just that those tools
> are shipping and functional, instead of existing only in the minds of
> PDF authors producing vaporware. We call these massive frameworks and
> tools HTTP clients and servers. It is a big mistake to build new
> massive frameworks on top of a massive framework if you don't need to.
>

I guess I just don't consider an http server or client library 'a
massive framework.' On the other hand, with 100+ million public web
sites, plus supporting servers, proxies, and so on, the entire
internet _infrastructure_ is massive. I interpreted Philip's statement
as referring to the tools to implement a specific application or site,
not the supporting infrastructure below that makes the implementation
possible.

With a REST architecture, it has been possible to build out that web
infrastructure over time, using whatever tools or frameworks are
appropriate for each site and it's content.  Some sites use simple
tools, some use complex frameworks.  Many started simple and grew over
time.  But they all interoperate nicely, with a low cost of entry in
terms of whats required to get started.  Tools and frameworks are good
things, the option to choose the appropriate tool for the job is even
better.  That is a REST advantage.

> Of course, now the software industry will now get to compete with a
> more clueful bunch of MS HTTP products, instead of the WS-Bogus
> nonsense you could immediately write off and never think about again.
> The Astoria stuff may not be the prettiest, but it looks to me like it
> will *actually work* without an army of consultants, which is a big
> ch

ange.
>
There definitely seems to be a shift to REST from WS-*.  With the
internet as a working reference implementation,  I can see why.

mike

--
mikeyp@...                                                   
http://www.snaplogic.org

On Thu, 2007-05-03 at 09:26 -0700, Mike Pittaro wrote:
> With a REST architecture, it has been possible to build out that web
> infrastructure over time, using whatever tools or frameworks are
> appropriate for each site and it's content. Some sites use simple
> tools, some use complex frameworks. Many started simple and grew over
> time. But they all interoperate nicely, with a low cost of entry in
> terms of whats required to get started. Tools and frameworks are good
> things, the option to choose the appropriate tool for the job is even
> better. That is a REST advantage.

Is it?  I think it's more a function of open (and libre-Free ones)
specifications and protocols.  Though REST does help to some degree.

--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}

On 5/3/07, Josh Sled <jsled@...> wrote:
> On Thu, 2007-05-03 at 09:26 -0700, Mike Pittaro wrote:
> > With a REST architecture, it has been possible to build out that web
> > infrastructure over time, using whatever tools or frameworks are
> > appropriate for each site and it's content. Some sites use simple
> > tools, some use complex frameworks. Many started simple and grew over
> > time. But they all interoperate nicely, with a low cost of entry in
> > terms of whats required to get started. Tools and frameworks are good
> > things, the option to choose the appropriate tool for the job is even
> > better. That is a REST advantage.
>
> Is it?  I think it's more a function of open (and libre-Free ones)
> specifications and protocols.  Though REST does help to some degree.

Sure.  REST helps by providing oodles of simplicity.

Mark.

Mike Pittaro wrote:
> There definitely seems to be a shift to REST from WS-*.  With the
> internet as a working reference implementation,  I can see why.

s/internet/Web/

On 5/3/07, Robert Sayre <sayrer@...> wrote:

> The Astoria stuff may not be the prettiest, but it looks to me like it
> will *actually work* without an army of consultants, which is a big
> change.


I thought requiring IBM Global Services was actually an official
requirement of many WS-* specifications.

Whatever you say about MS, their interest is in ensuring that Windows
remains the platform for client and server development, that the MS
office server suite is the back end for future apps, and that MS
office file formats remain in charge. The format for documents is a
lot more strategic to them than how you upload it to a service.

They've also had RESTy stuff in the past, in Exchange, for example.
The company embraced SOAP but it was, in the early days, DCOM in XML.

-steve

p.s, say what you like about SOAP, but in REST, the enemy of GET  is
the proxy server that thinks it knows better. The one that returns
200+text/html when the far end 401s on you. The one that caches stuff
for weeks, even when the TTL is seconds. The one that caches an
incomplete download and serves up to other callers.

On 5/1/07, Mark Baker <distobj@...> wrote:
> LOL.  These guys tried to recruit me about a couple years ago (Pablo
> Castro, in fact - mentioned on the page).  I kept telling them they
> needed to put an HTTP interface on their stuff, and they just couldn't
> grok it.  No, they didn't realize who I was. 8-)


I visited building 42 a few years back to explore gainful employment
opportunities, but they threw me out before lunch. This was while I
still thought SOAP was a good idea, so the reason I was marched off
the premises was competence rather than ideology.

With hindsight, it was a near miss, even if the skiing there is better
than in the UK.

-steve

"Steve Loughran" <steve.loughran.soapbuilders@...> writes:

> p.s, say what you like about SOAP, but in REST, the enemy of GET  is
> the proxy server that thinks it knows better. The one that returns
> 200+text/html when the far end 401s on you. The one that caches stuff
> for weeks, even when the TTL is seconds. The one that caches an
> incomplete download and serves up to other callers.

Errmmmm... isn't this true of SOAP as well?

A proxy that was that badly implemented (and I agree that some proxies
ARE that badly implemented) would fek up a SOAP call as well.


--
Nic Ferrier
http://www.tapsellferrier.co.uk

On 4-May-07, at 6:01 AM, Steve Loughran wrote:

> On 5/3/07, Robert Sayre <sayrer@...> wrote:
>
> > The Astoria stuff may not be the prettiest, but it looks to me
> like it
> > will *actually work* without an army of consultants, which is a big
> > change.
>
> I thought requiring IBM Global Services was actually an official
> requirement of many WS-* specifications.
>
> Whatever you say about MS, their interest is in ensuring that Windows
> remains the platform for client and server development, that the MS
> office server suite is the back end for future apps, and that MS
> office file formats remain in charge.


Yes. That is their one and only strategy for staying in business, and
is the lens through which all of their products or announcements
should be viewed.

--T

> The format for documents is a
> lot more strategic to them than how you upload it to a service.
> ...

Nic James Ferrier wrote:
>
>
> "Steve Loughran" <steve.loughran.soapbuilders@...
> <mailto:steve.loughran.soapbuilders%40gmail.com>> writes:
>
>  > p.s, say what you like about SOAP, but in REST, the enemy of GET is
>  > the proxy server that thinks it knows better. The one that returns
>  > 200+text/html when the far end 401s on you. The one that caches stuff
>  > for weeks, even when the TTL is seconds. The one that caches an
>  > incomplete download and serves up to other callers.
>
> Errmmmm... isn't this true of SOAP as well?
>
> A proxy that was that badly implemented (and I agree that some proxies
> ARE that badly implemented) would fek up a SOAP call as well.

Not in the good old days when all SOAP calls ran over POST.

cheers
Bill

On Thu, 2007-05-03 at 15:15 -0400, Mark Baker wrote:
> On 5/3/07, Josh Sled <jsled@...> wrote:
> > On Thu, 2007-05-03 at 09:26 -0700, Mike Pittaro wrote:
> > > With a REST architecture, it has been possible to build out that web
> > > infrastructure over time, using whatever tools or frameworks are
> > > appropriate for each site and it's content. Some sites use simple
> > > tools, some use complex frameworks. Many started simple and grew over
> > > time. But they all interoperate nicely, with a low cost of entry in
> > > terms of whats required to get started. Tools and frameworks are good
> > > things, the option to choose the appropriate tool for the job is even
> > > better. That is a REST advantage.
> >
> > Is it?  I think it's more a function of open (and libre-Free ones)
> > specifications and protocols.  Though REST does help to some degree.
>
> Sure.  REST helps by providing oodles of simplicity.

That's true. I underestimated this.

The full combination of things REST defines (and HTTP provides) are
quite complex.  That is, a trivial GET is straightforward, but add in:

- specified operation semantics
- cache-control headers
- separate content- and transfer-encoding
- content negotiation
- language negotiation
- conditional requests
- ranged requests
- media types
- hierarchical status codes

... it's certainly more complex than a naïve "send serialized operation
& arguments, get serialized response" protocol could be.


Simplicity comes throughout the usage spectrum, though.  At the "far"
end, the overall system after you sum up all the features that those
add-ins support is far simpler than other approaches.

But at the other side – and more importantly for thinking about the
growth of the web, I think – it also "degrades" simply: you really can
just say:

    $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80

and it will work.  And many solutions can be implemented with requests
on this order of complexity.


I was thinking that at this "small" side – which imho is more important
w.r.t. the growth of the web – it's not so much about REST, as it is
that HTTP and HTML are open.  But, the interoperable growth of the web
is due to both RESTful uniform operations with clearly defined behavior
for intermediaries (especially for the "simple" requests).  But I think
the ability to read and implement open specs for those semantics is
pretty important, as well.

--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}

On 4-May-07, at 11:59 AM, Josh Sled wrote:

> ... it also "degrades" simply: you really can
> just say:
>
>    $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80

Pedantically speaking, so will:
	 $ curl http://host/foo

On Fri, 2007-05-04 at 12:28 -0300, Toby Thain wrote:
> On 4-May-07, at 11:59 AM, Josh Sled wrote:
>
> > ... it also "degrades" simply: you really can
> > just say:
> >
> >    $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80
>
> Pedantically speaking, so will:
>  $ curl http://host/foo

Indeed.  I wanted to be a level lower than curl/wget, even. :)

--
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo ${a}@${b}

* Toby Thain <toby@...> [2007-05-04 17:30]:
> On 4-May-07, at 11:59 AM, Josh Sled wrote:
>
> > ... it also "degrades" simply: you really can just say:
> >
> >    $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80
>
> Pedantically speaking, so will:
>  $ curl http://host/foo

Yeah, but curl is explicitly an HTTP client, whereas nc doesn’t
implement anything beyond TCP.

However, HTTP sticks to the essentials so well that you need
nothing more than a TCP implementation to get useful work done.
Sure, your code won’t be very generic – in fact it will implement
almost none of the spec. But it doesn’t have to if you don’t need
it to.

HTTP scales *down* as effortlessly as it scales up.

Which I think was Josh’s point.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

On 4-May-07, at 2:19 PM, A. Pagaltzis wrote:

> * Toby Thain <toby@...> [2007-05-04 17:30]:
> > On 4-May-07, at 11:59 AM, Josh Sled wrote:
> >
> > > ... it also "degrades" simply: you really can just say:
> > >
> > > $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80
> >
> > Pedantically speaking, so will:
> > $ curl http://host/foo
>
> Yeah, but curl is explicitly an HTTP client, whereas nc doesn’t
> implement anything beyond TCP.

Yeah, I didn't get Josh's point at first. Since corrected. :-)

>
> However, HTTP sticks to the essentials so well that you need
> nothing more than a TCP implementation to get useful work done. ...