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

Re: i28 proposed replacement text

From: Jamie Lokier <jamie@shareable.org>
Date: Tue, 3 Jun 2008 10:01:01 +0100
To: Yves Lafon <ylafon@w3.org>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Message-ID: <20080603090100.GA25172@shareable.org>

Yves Lafon wrote:
> My issue is not about interaction between 1.0 and 1.1, but more about 
> integrity/error detection in 1.1.
> In p1 3.4:
> <<
>    Whenever a transfer-coding is applied to a message-body, the set of
>    transfer-codings MUST include "chunked", unless the message is
>    terminated by closing the connection.  When the "chunked" transfer-
>    coding is used, it MUST be the last transfer-coding applied to the
>    message-body.  The "chunked" transfer-coding MUST NOT be applied more
>    than once to a message-body.  These rules allow the recipient to
>    determine the transfer-length of the message (Section 4.4).
> >>
> Should we add there or in Section 4.4 something like:
> <<
>   If the transfer-length is defined by closing the connection, the
>   integrity of the message is not guaranteed, unless it is a
>   characteristic of the transfer-coding used. 'Identity' does not have
>   this characteristic.
> >>
> ?

   Because closing is used to abort in some error scenarios, if the
   transfer-length is defined by closing the connection, the recipient
   cannot be sure the whole message is received, unless the
   transfer-coding unambiguously detects truncation.  The
   transfer-codings 'identity', 'deflate' and 'gzip' do not have this
   characteristic, although in most cases 'deflate' and 'gzip' will
   detect truncation.  Content-encoding and type-specific syntax of
   the received entity may also detect truncation, but truncation of
   entity syntax does not always indicate a transport error.

-- Jamie
Received on Tuesday, 3 June 2008 09:01:43 UTC

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