Re: Content-Length and 304

+1 -T

On Sat, Sep 22, 2012 at 12: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