- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 5 Jun 2008 09:55:04 -0400 (EDT)
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>, Henrik Nordstrom <henrik@henriknordstrom.net>, Julian Reschke <julian.reschke@gmx.de>, Jamie Lokier <jamie@shareable.org>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
On Thu, 5 Jun 2008, Adrien de Croy wrote:
> connection closure only signals end of message if the message had no
> Content-Length header, and was not chunked.
>
> Otherwise, if there is a Content-Length header, (and not chunked) then the
> message is complete when the number of bytes indicated have been received.
> The connection can then be kept open (classic Connection: keep-alive without
> chunking).
[..]
> Therefore it makes sense for the proxy to simply abortively close the
> connection to the client and let the client deal with it, that then conveys
> the (useful) information to the client that the transfer was aborted.
The issue seems to be message integrity (which can be somehow assessed by
the receiving end) and entity integrity (only applications can try to do
that).
In Henrik's example, the proxy wasn't able to assess that the received
message was complete or not (at the HTTP level), and it won't try to
inspect it. On the other side, the client talking to the proxy will
receive a complete message, however the entity carried maynot be complete.
The proxy may add a Warning header to indicate this, it would be a better
match than closing the connection in the middle of a chunk.
One question is... if a Transfer encoding of gzip is used + connection
closure form the server to the proxy, and the client sent a TE: gzip to
the proxy, should the proxy gunzip the content, then gzip it back (as
TE/TEncoding is hop-by-hop) ? (and it that case an error may be noticed) ?
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Thursday, 5 June 2008 13:55:38 UTC