- 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
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). Regards Henrik
Received on Monday, 12 May 2008 17:18:06 UTC