Re: Content-Length and 304

Roy, that’s a hairy diff, I was having trouble with it, 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

On Fri, Sep 21, 2012 at 10:11 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Sep 19, 2012, at 6:22 PM, Zhong Yu wrote:
>
> > In the latest bis draft, a 304 response SHOULD set Content-Length
> > equal to the length of the would-be payload body.
> >
> > ====
> >
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.2
> > 3.3.2. Content-Length
> >
> > ... a Content-Length header field SHOULD be sent to indicate the
> > length of the payload body that ... would have been present had the
> > request been an unconditional GET.
> >
> > ...In the case of a 304 response to a GET request, Content-Length
> > indicates the size of the payload body that would have been sent in a
> > 200 response.
> > ====
> >
> >
> > However, RFC2616 was not specific on the matter. If a server
> > implementation always sets "Content-Length: 0" for 304 responses, it
> > was acceptable.
>
> No, that has never been acceptable --- a change in content-length
> will cause a cache flush on many deployed implementations
> (Netscape introduced that in the mid 90s), and will truncate
> valid responses in others.
>
> Depending on how you read 2616, the SHOULD send Content-Length
> did not apply to messages that are not allowed to have a body.
> Hence, it was considered valid to not send Content-Length on 304.
> I messed that up when I merged the several paragraphs into
> one requirement.
>
> I have attempted a fix in
>
>   http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908
>
> that should remove any ambiguity about when content-length is
> sent.  Please review.
>
> ....Roy
>
>
>