Re: i28 proposed replacement text

On fre, 2008-05-09 at 16:01 +1000, Mark Nottingham wrote:
> Last call. Current proposal:
> 
> ref: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28
> 
> In section 4.4 the current text is:
> <<<
>    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),
>      unless the message is terminated by closing the connection.
> >>>
> 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.

The 'Content-Length' and 'multipart/byteranges' rules do not apply to
messages using any form of transfer encoding. When transfer-encoding is
used the only methods available for delimiting the messages is chunked
transfer encoding or when chunked is not used by closing the connection.

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.

Regards
Henrik