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: Tue, 3 Jun 2008 04:41:55 -0400 (EDT)
To: Jamie Lokier <jamie@shareable.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: <Pine.LNX.4.64.0806030421530.19310@ubzre.j3.bet>

On Mon, 2 Jun 2008, Jamie Lokier wrote:

>>> Chunked encoding clearly is not the norm when sending compressed
>>> dynamic content to a HTTP/1.0 client.
>> We are talking about transfer-encoding and message delimiting, not
>> content-encoding.
> True, but the same message integrity issues w.r.t connection aborts
> apply to Content-Encoding used for compressed dynamic content.  Since
> that is how it's done most often right now, it seems relevant.

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.

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

Received on Tuesday, 3 June 2008 08:42:30 UTC

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