- From: Yves Lafon <ylafon@w3.org>
- Date: Fri, 18 Apr 2008 08:14:43 -0400 (EDT)
- To: Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org
On Thu, 3 Apr 2008, Mark Nottingham wrote:
> Yves,
>
> Do you mean:
>
>> 2: If a Transfer-Encoding header field (Section 14.41) is present, and
>> has any value other than "identity", then the transfer-length is
>> defined by use of the "chunked" transfer-coding (Section 3.6).
>
> ? (I think there was a cut-and-paste error, perhaps).
Yes, as there is already a MUST (use chunked transfer-coding) in part 02,
section 3.4
> If so, +1.
>
> One comment -- this is good, but my reading of the "unless the message is
> terminated..." text is that it was intended to cover the case where the
> connection is prematurely closed. It may be useful to have text added below
> the numbered list along these lines;
>
> """
> If a message has a defined length (e.g., using chunked encoding,
> Content-Length, or multipart/byteranges), and the connection is prematurely
> closed, then the transfer-length will be less than indicated, and the message
> is incomplete.
> """
+1
We can also add that it's an error (even if it seems obvious)
> This leaves the question open of whether we want to place any additional
> requirements on incomplete messages (which should probably be considered
> separately).
We can't say, from such an error, if it's used to signal an error, or if
it is an unplanned error, also there is the issue of partial cache such
responses to a GET, or what to do when it's a POST. It all goes in the
"error recovery" bucket...
We have some error recovery (as in part 1, 7.2.4), something on the same
lines for this case should be ok.
Cheers,
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Friday, 18 April 2008 12:15:13 UTC