Re: i28 proposed replacement text

On Tue, 3 Jun 2008, Henrik Nordstrom wrote:

> I don't see why as this isn't a guaranteed even if chunking is used in
> the hop to the receiver.
>
> Chain may be
>
> server [Connection: close, no TE] -> proxy [Transfer-Encoding: chunked]
> -> recipient
>
> In which case receiving a properly terminated chunked encoding says
> nothing about if the message was truncated in transit or not.

Well, in that case, it would be better for the proxy to figure out there 
is a potential error from server to proxy and to something clever (cutting 
the connection without sending the last chunk ?) to signal this.

> Denying upgrading from Connection: close to Transfer-Encoding: chunked
> would work around this, but at a significant performance penalty and
> also uncertain as such upgrading is actively done by deployed RFC2616
> compliant implementations.
>
> Integrity is not a property of the transport. The transport is
> hop-by-hop and must only guarantee internal consistency, allowing
> unambigious parsing of the data stream. Integrity checks should be done
> at the message level.

Integrity is also a hop-by-hop property. For end-to-end, Content-MD5 and 
others are here to help.

>
> But I am in favor for stating that if the transfer encoding could not be
> properly decoded (decompression error in gzip/deflate, missing end chunk
> in chunked etc..) or if network errors is detected while receiving the
> message (i.e. read error or similar) the message SHOULD be considered
> invalid and the connection closed. Implementations MUST NOT try to
> continue using a connection after a transport error including
> transfer-encoding related issues.
>
> Regards
> Henrik
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 3 June 2008 16:35:00 UTC