- 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
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 UTC