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

Miles wrote:
>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?
>

It was, in HTTP/1.0 or 0.9, wasn't it?  The answer I've received to this
question is that EOF isn't a request entity delimiter in HTTP/1.1 because
in HTTP/1.1 connections are persistent (by default).

>> 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.
>

There is a popular API can't do half-closes:  Java.  At least until
recently, a close() in Java closes both sides of the connection (even if
only applied to the InputStream or OutputStream obtained from the Socket).

>> 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/
>

     -Carl

Received on Monday, 19 March 2001 09:13:08 UTC