- 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
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.
~~Yves
Received on Monday, 2 June 2008 07:11:03 UTC