Re: i28 proposed replacement text

Stepping back, the original issue was that the phrase "terminated by  
closing the connection" is vague; it doesn't say how the connection is  
closed, or who does it.

In 2616 3.6:
> 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.

In 2616 4.4:
> 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.

In both of these cases, it may be better to say something like "unless  
the message indicates it is terminated by closing the connection  
(i.e., with Connection: close)."

As Henrik noted, we've removed "identity", so that should be factored  
out as well. This leaves (for 4.4):

If a Transfer-Encoding header field (section 14.41) is present, then  
the transfer-length is defined by use of the "chunked" transfer-coding  
(section 3.6), unless the message indicates it is terminated by  
closing the connection.

This addresses the case that H brought up;

HTTP/1.1 200 OK
Transfer-Encoding: gzip
Connection: close

but is unclear about this:

HTTP/1.1 200 OK
Transfer-Encoding, gzip, chunked
Connection: close

What determines the tranfser-length here?

Changing things to refer explicitly to "chunked" may help;

2. If the Transfer-Encoding header field (section 14.41) is present  
and contains the "chunked" value, the transfer-length is defined by  
the use of the "chunked" transfer encoding.

Note that 3.6 already requires that the chunked value be listed if  
chunking is in use.

3.6 would still benefit from:
Whenever a transfer-coding is applied to a message-body, the set of  
transfer-codings MUST include "chunked", unless the message indicates  
it is terminated by closing the connection.




On 13/05/2008, at 3:17 AM, Henrik Nordstrom wrote:

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


--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 23 May 2008 04:31:08 UTC