Re: Content-Length and 304

I did not know C-L in 304 had a meaning on many deployed
implementations, thanks for clarify and include that meaning in the
spec.

I'm still not quite clear about the benefit though. Any use case where
a C-L in 304 is better than no C-L? Is it alright for a server to
categorically exclude C-L in 304s?

Zhong Yu

On Sat, Sep 22, 2012 at 2:07 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Sep 21, 2012, at 10:59 PM, Tim Bray wrote:
>
>> Roy, that’s a hairy diff, I was having trouble with it,
>
> It is easier if you skip the html part and just look at the
> diff on the xml source.  Next time I will remember to include the
> fragment ...
>
>  http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908#file1
>
>> but I think it’s saying that you MAY send a CL with a 304 containing the correct size, which is what we want.  Given the record of bad practice in this space, might it be worth while to say the server MUST NOT act stupid and send a 0 or anything else inaccurate? -T
>
> Given the unbounded set of stupid things a server might do,
> I'd rather not.  However, I can restrict it further.
>
> Instead of
>
>    A server &MAY; send a Content-Length header field in a
>    <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request
>    (&status-304;) in order to indicate the size of the payload body,
>    excluding any potential transfer-coding, that would have been sent in a
>    <x:ref>200 (OK)</x:ref> response.
>
> how about
>
>    A server &MAY; send a Content-Length header field in a
>    <x:ref>304 (Not Modified)</x:ref> response to a conditional GET request
>    (&status-304;); a server &MUST-NOT; send Content-Length in such a response
>    unless its field-value equals the decimal number of octets that would
>    have been sent in the payload body of a <x:ref>200 (OK)</x:ref> response
>    to the same request.
>
> Cheers,
>
> ....Roy

Received on Saturday, 22 September 2012 17:25:05 UTC