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

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 03 Jun 2008 13:41:19 +0200
To: Yves Lafon <ylafon@w3.org>
Cc: Jamie Lokier <jamie@shareable.org>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Message-Id: <1212493279.32680.9.camel@hlaptop.henriknordstrom.net>

tis 2008-06-03 klockan 04:41 -0400 skrev Yves Lafon:

> Should we add there or in Section 4.4 something like:
> <<
>    If the transfer-length is defined by closing the connection, the
>    integrity of the message is not guaranteed, unless it is a
>    characteristic of the transfer-coding used. 'Identity' does not have
>    this characteristic.
> >>
> ?

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.

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.

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.

Received on Tuesday, 3 June 2008 11:42:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC