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

Re: i28 proposed replacement text

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
Message-ID: <Pine.LNX.4.64.0804180750110.28224@ubzre.j3.bet>

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.
> """

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.

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

Received on Friday, 18 April 2008 12:15:13 UTC

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