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

Re: i28 proposed replacement text

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 9 May 2008 16:01:02 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <C971F3E0-F116-4147-BA6B-04D941E360E9@mnot.net>
To: Yves Lafon <ylafon@w3.org>

Last call. Current proposal:

ref: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28

In section 4.4 the current text is:
<<<
   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),
     unless the message is terminated by closing the connection.
>>>
Here is the porposed clarification text:
<<<
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)
>>>



On 18/04/2008, at 10:14 PM, Yves Lafon wrote:

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


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 9 May 2008 06:01:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:47 GMT