- 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
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. Regards Henrik
Received on Tuesday, 3 June 2008 11:42:18 UTC