W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Mon, 12 May 2008 19:17:19 +0200
To: Brian Smith <brian@briansmith.org>
Cc: Jamie Lokier <jamie@shareable.org>, Yves Lafon <ylafon@w3.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-Id: <1210612639.3442.5.camel@henriknordstrom.net>

On mån, 2008-05-12 at 09:54 -0700, Brian Smith wrote:

> Does this mean that it isn't possible to use deflate or gzip 
> Transfer-Encoding on a persistent connection unless chunked encoding is 
> applied (last)?

Correct. If transfer encodings is applied to the message and chunked
encoding isn't used the connection MUST be closed after the message to
signal end-of-message.

> And, doesn't the following imply that any 
> transfer-encoding (besides identity) must be chunked? That is, "deflate" 
> would not be a valid Transfer-Encoding, but "deflate, chunked" would me.
>     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.

No. See the last section "unless the message is terminated by closing
the connection". It's a bit vague however and some people have misread
it and that is what this issue is about.

See also the section on Transfer Encoding. The rules for message
delimiting when using transfer encoding is explained quite well there:

p1 3.4 Transfer Encodings

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).

Received on Monday, 12 May 2008 17:18:06 UTC

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