- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 10 Apr 2020 13:04:51 +0200
- To: Olivier Boel EXT <olivier.boel@clearstream.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hello, On Thu, Apr 09, 2020 at 12:42:24PM +0000, Olivier Boel EXT wrote: > as the server already sent a final status (meaning "the request-line and > header fields are sufficient to cause an immediate success, redirect, or > error response"), client should understand it is not worthwhile to send the > message body before actually doing so (which can improve efficiency when the > message body is huge or when the client anticipates that an error is likely) > even though server says "Connection: keep-alive", but rather send the next > request. This is not possible in HTTP/1 because the framing depends on the body to reach its end. At best if the client uses the chunked transfer coding then it may perform an early abort by completing the current chunk and sending the zero-sized chunk to mark the end of the transfer. But as long as XXX bytes were promised in content-length there is no way the client can abort this and keep the connection alive: how would the server know that finally those bytes will not come ? All the server knows in such a case is that everything that follows the headers for XXX bytes is supposed to be the request's body, and that it's only after these ones that a new request may appear. Hoping this helps, Willy
Received on Friday, 10 April 2020 11:05:11 UTC