W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2001

RE: HTTP and half close (WAS: HTTP client abort detection)

From: Miles Sabin <MSabin@interx.com>
Date: Sat, 17 Mar 2001 09:37:30 -0000
Message-ID: <69B15B675E99D411A4110008C786DA23DED728@exwest_01.interx.com>
To: http-wg@cuckoo.hpl.hp.com
Roy T. Fielding wrote,
> Using the typical socket API with TCP, an HTTP connection is 
> considered to be closed when it receives a fatal error or EOF 
> either:
>
>  1) when attempting to read an unfinished request and there 
>     are no pending responses being sent on the connection 
>     (this is easily determined because all HTTP requests are 
>     length-delimited), or
>
>  2) when writing a response.

So, in other words, the type 1 clients of my previous posting
(early half close) are correct, and the type B servers of my
previous posting (early EOF implies client abort) are incorrect.

That's all very well, but it's only one of the possible choices 
for the mapping of TCP/socket API behaviour on to HTTP behaviour.
It'd be nice to have some justification for why the choice should 
be made this way rather than some other, and some reassurance 
that this is the way the choice has been made in real 
implementations. 

It also leaves me puzzled about the question of delimiting
request entities. If a client TCP half close *isn't* considered 
as an HTTP connection close, then why can't we use that that as 
an alternative to Content-Length or chunking? Given what you've
said above, the parenthesis in,

   5.By the server closing the connection. (Closing the 
     connection cannot be used to indicate the end of a request 
     body, since that would leave no possibility for the server 
     to send back a response.)

simply doesn't apply. Why not allow EOF as a request entity
delimiter?

> Note that the above applies to the socket API.  There may be a 
> completely different algorithm for determining when the 
> connection is closed when using other API, particularly event-
> based ones.

Could you elaborate on this? It seems to imply that we might
have client and server HTTP over TCP implementations, one built 
on the socket API, one built on something else, each with
different mappings of TCP behaviour to HTTP behaviour, hence that 
the two might not be fully interoperable. I'm not sufficiently 
familiar with non-socket APIs to say whether this would be likely 
to be a problem in practice, but it certainly seems like a 
worrying prospect.

> The reason this isn't defined in the HTTP spec is because it is 
> not an interoperability issue for the application protocol -- 
> it is an implementation detail that is entirely dependent on 
> the nature of the lower-layer API used by the application.  It 
> is the stuff for a good book on network programming.

Perhaps it's not an issue for the abstract protocol, but it is
an issue for it's most common concrete realization. Isn't this
sort of interaction between the transport layer and the
application layer precisely the sort of thing which prompted
Jim Gettys and Alan Freiers "HTTP Connection Management" ID?

On the face of it, it'd be useful to have one or more transport
layer specific profiles as adjuncts to the abstract protocol
specification.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/
Received on Saturday, 17 March 2001 09:41:56 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:41 EDT