- From: Jamie Lokier <jamie@shareable.org>
- Date: Mon, 18 May 2009 05:34:48 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Daniel Stenberg <daniel@haxx.se>, HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote: > > Jamie Lokier wrote: > >Adrien de Croy wrote: > > > >>If no Content-Length field is present, and no Transfer-Encoding > >>specified, then presumably for any request there will be no entity, > >>since the client would need to disconnect to signal the end of the > >>entity body. > >> > > > >Disconnecting to signal the end of the body is only allowed for > >responses. For requests, it would need to be a TCP half-close and > >that is not mentioned at all in HTTP, and probably not supported by > >most/all servers. > > > > > that's the basis I've been operating under. Was just wondering if it > were explictly prohibited by the spec or not. > > Since I didn't want to presume there can be no application where it may > be valid to send an entity body in a request and then disconnect (i.e. > if not interested in the response). Which reminds me. Real HTTP servers like Apache must not close the connection to signal the end of a response. They *half-close* it using the shutdown() socket function, and then sit for a while discarding any subsequent request which might have been pipelined. This is necessary, because if any further data is received by a *fully*-closed TCP socket on the server, the servers's TCP will reset the connection and send a RST packet, which causes the server to abort *sending* any data which it hasn't yet transmitted successfully, and cause most clients to abort *receiving* the response, and sometimes abort sending data it has received up to the receiving application. In other words, HTTP pipelining requires servers to half-close instead of fully-closing and then do a "lingering close" dance, if they send a response whose end is signalled by closing the connection. If they don't do that, responses can be lost depending on transient network conditions. This is necessary even if the reponse has "Connection: close", because the client may still have sent further request bytes before it sees any part of the response. Since this is required for reliable HTTP pipelining over TCP, it should be mentioned somewhere in an HTTP specification. It isn't in RFC 2616 anywhere that I could see. -- Jamie
Received on Monday, 18 May 2009 04:35:23 UTC