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

Re: i28 proposed replacement text

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 2 Jun 2008 03:10:28 -0400 (EDT)
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, Jamie Lokier <jamie@shareable.org>, ietf-http-wg@w3.org
Message-ID: <Pine.LNX.4.64.0806020302150.20520@ubzre.j3.bet>

On Wed, 28 May 2008, Henrik Nordstrom wrote:

> On ons, 2008-05-28 at 10:41 -0400, Yves Lafon wrote:
>> Then we must at least say that the encoding used (not chunked) must
>> give the same characteristics as chunked wrt detection of the end of the
>> message.
> Why? The protocol will not fall down if a message is unexpectedly cut
> short.

Essentially for what it below, the need to verify the integrity of the 
message. It is needed when you don't cut the connection, but it is a 
desirable property even if the connection is cut, to detect an error case 
(like cutting the connection in the middle of a chunked stream) from a 
normal response.

> A note mentioning that this may downgrade the message integrity to the
> level of a Connection: close without Content-Length message may be
> acceptable, but not a must. In practice most file formats and encodings
> easily detect truncation.

partial or absolute detection ? If the format allows multiple concatenated 
entries, and integrity check is true if you reach exactly the end of one 
entry, you have a highly probable integrity check but not an absolute one.

In any case, a note explaining that it might be difficult to figure out 
the integrity of the message in this case would be sufficient.

>> Is this particular case really used in deployed client/servers, and done
>> the right way ?
> As already mentioned both gzip and deflate has this property to a
> sufficient level.

But it is used that way in deployed servers/clients ? Or is chunked 
encoding always the norm.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Monday, 2 June 2008 07:11:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC