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

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 02 Jul 2008 22:29:36 +0200
To: Yves Lafon <ylafon@w3.org>
Cc: ietf-http-wg@w3.org
Message-Id: <1215030576.23148.20.camel@henriknordstrom.net>
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.


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

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.

> As it doesn't make much sense for a client to close the connection after 
> sending an entity using TE without chunk, we can just replace [the 
> emitter] (in [] just to show it needs a better wording) by 'the server'.
> Cheers,



Received on Wednesday, 2 July 2008 20:30:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:36 UTC