W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Sat, 24 May 2008 11:57:45 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, Jamie Lokier <jamie@shareable.org>, Yves Lafon <ylafon@w3.org>, ietf-http-wg@w3.org
Message-Id: <1211623065.27257.13.camel@henriknordstrom.net>
On lör, 2008-05-24 at 11:51 +0200, Henrik Nordstrom wrote:
> On lör, 2008-05-24 at 09:52 +0200, Julian Reschke wrote:
> 
> > With chunked encoding in use, how does the sender of a message indicates 
> > an error? (such as when serving a file from the file system, and getting 
> > an IO error)
> 
> By closing the connection in the middle of the response without sending
> the last-chunk.

Or if you meant "Witch chunked encoding NOT in use" then it's still the
same, by closing the connection in the middle of the response. How easy
the error is to detect for the recipient then depends on the encoding or
format of the response.

T-E: gzip/deflate both have stream structure and clearly indicates
premature closure (except for the hypothetical case of a sender sending
multiple members in a gzip stream and crashing just between two
members).

If no T-E is used and Content-Length is used then it's trivially
detected by the response beeing too short.

If no T-E is used and no Content-Length then it's tricker as the receier
then has to fully parse the response and from that judge if it's
complete or not, and then guess if this is due to a server failure or if
the object at the server really is corrupted/truncated...

Regards
Henrik

Received on Saturday, 24 May 2008 09:58:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:48 GMT