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, 12 May 2008 05:42:37 -0400 (EDT)
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-ID: <Pine.LNX.4.64.0805120538020.15846@ubzre.j3.bet>

On Mon, 12 May 2008, Henrik Nordstrom wrote:

>>>>>
>> Here is the porposed clarification text:
>> <<<
>> 2: If a Transfer-Encoding header field (Section 14.41) is present, and
>>     has any value other than "identity", then the transfer-length is
>>     defined by use of the "chunked" transfer-coding (Section 3.6)
>>>>>
>
> No, this is wrong. See the section on transfer encoding.
>
> The following message header is perfectly legal and is what the "closing
> the connection" part is about:
>
> HTTP/1.1 200 OK
> Transfer-Encoding: gzip
> Connection: close
>
>
> What it should read is something like the following:
>
> 2. If a Transfer-Encoding header field (Section 14.41) is present, and
>   indicates that "chunked" was the last encoding applied to the
>   message-body then the transfer-length is defined by use of the
>   "chunked" transfer-coding (Section 3.6).
>
> 3. If a Transfer-Encoding header field (Section 14.41) is present, and
>   has a value other than "identity", then the transfer-length
>   is defined by closing the connection.

And in that case, you have no guarantee that the message in complete or 
not (unless you use a Transfer-Encoding that gives that property, if the 
recipient knows about this encoding, which is not granted.

> Side Note: It's illegal to apply any transfer-encoding after chunked
> encoding simply because it would be a complete waste. Technically the
> message format do support inner levels of chunked encoding.


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

         ~~Yves
Received on Monday, 12 May 2008 09:43:10 GMT

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