Re: i28 proposed replacement text

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