Subject: Re: i28 proposed replacement text

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Apr 2008 13:18:05 +1100

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

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

This leaves the question open of whether we want to place any  
additional requirements on incomplete messages (which should probably  
be considered separately).

Cheers,

On 26/04/2007, at 12:17 AM, Yves Lafon wrote:

>
> 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 "chunked"
>    transfer-coding is used, then the transfer-length is
>    defined by use of the "chunked" transfer-coding (Section 3.6)
>>>>
> Even if any value other than "identity" implies that "chunked" MUST  
> be here, it is less prone to interpretations.
>
> The "unless the message is terminated by closing the connection"  
> would mean that we are using Transfer-Encoding on an HTTP/1.0, and  
> close the connection to signal the end, in that case, it is already  
> covered by item 5 with the caveat right after "For compatibility  
> with HTTP/1.0 applications..."
>
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Yves Lafon <[email-masked]>
Date: Fri, 18 Apr 2008 08:14:43 -0400 (EDT)

> ? (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;
>
> """
> 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,

         ~~Yves