- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 3 Jun 2008 10:01:01 +0100
- To: Yves Lafon <ylafon@w3.org>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Joe Orton <joe@manyfish.co.uk>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Yves Lafon wrote: > My issue is not about interaction between 1.0 and 1.1, but more about > integrity/error detection in 1.1. > > In p1 3.4: > << > Whenever a transfer-coding is applied to a message-body, the set of > transfer-codings MUST include "chunked", unless the message is > terminated by closing the connection. When the "chunked" transfer- > coding is used, it MUST be the last transfer-coding applied to the > message-body. The "chunked" transfer-coding MUST NOT be applied more > than once to a message-body. These rules allow the recipient to > determine the transfer-length of the message (Section 4.4). > >> > > 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. > >> > ? << Because closing is used to abort in some error scenarios, if the transfer-length is defined by closing the connection, the recipient cannot be sure the whole message is received, unless the transfer-coding unambiguously detects truncation. The transfer-codings 'identity', 'deflate' and 'gzip' do not have this characteristic, although in most cases 'deflate' and 'gzip' will detect truncation. Content-encoding and type-specific syntax of the received entity may also detect truncation, but truncation of entity syntax does not always indicate a transport error. >> -- Jamie
Received on Tuesday, 3 June 2008 09:01:43 UTC