Re: i28 proposed replacement text

Henrik Nordstrom wrote:
> On ons, 2008-07-02 at 13:05 -0400, Yves Lafon wrote:
>> To sum up, the current text should not be changed, as it is valid to cut 
>> the connection to signal the end of the tranfer, even if Transfer-Encoding 
>> is used _without_ using chunked encoding.
>>
>> However, if it was raised as an issue, it deserves clarification, and most 
>> probably a warning.
> 
> Agreed.
> 
>> So, in 4.4, item 2:
>>
>> <<<
>> 2.  If a Transfer-Encoding header field (Section 8.7) is present,
>>         then the transfer-length is defined by use of the "chunked"
>>         transfer-coding (Section 3.4), unless the message is terminated
>>         by closing the connection.
>> replaced by
>> <<<
>> 2.  If a Transfer-Encoding header field (Section 8.7) is present, and
>>         the "chunked" transfed-coding (Section 3.4) is used, the
>>         transfer-length is defined by the use of this transfer-coding.
>>         If the "chunked" transfer-coding is not present, the
>>         transfer-length is defined by [the emitter] closing the connection.

Can we rephrase that without using the term "emitter" (is the the same 
as "sender"?), and without brackets?

>>         Warning: If the transfer-length is defined by closing the
>>         connection, the transfer-coding used might not have characteristics
>>         to ensure that the  sender and the recipient sent/received the same
>>         message.
> 
> Looks fine. But I think the warning part is overkill and only confuses
> matters, but won't object it if others thinks it's needed.

Do we have consensus for at least making the first part of the change 
(with "[the emitter]" being replaced as suggested below)?

> I've already said many times that HTTP does not strictly provide this
> guarantee even if chunked is used as the chunking may have been added
> along the path.
> 
> If energy is to be spent on explaining the "message integrity"
> properties of HTTP then some better wording on what constitutes an
> incomplete message, and how recipients should act when seeing one,
> especially proxies.. But most seems to get this right by intuition, but
> I think it's important to add that a proxy detecting a partial message
> by seeing a connetion close either before Content-Length octets or
> before a chunked end-chunk when the message is using chunked SHOULD
> close the proxied connection without signalling the end-chunk to the
> recipient, and that caches MUST consider the message partial. This to
> avoid the next-hop mistakenly beleiving the partial message is proper.

Sounds good. Can you propose text for Part 6, covering this?

> ...

BR, Julian

Received on Wednesday, 2 July 2008 21:14:02 UTC