W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Content-Length and 304

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Sat, 22 Sep 2012 12:09:48 -0400
Message-ID: <CAMm+Lwg_K305AAy32b741WMkmsXiLEs8ihxQE7kyP-14nRR6yQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
That looks good to me:

The length of the body section MUST be specified whenever there is a body.
This MAY be indicated using Content-Length or Chunked ecoding [or MAY be
some other negotiated encoding]

Content-Length MAY be specified for a 304 response (and possibly a list of
others) and MUST be the length of the content referenced if specified.

I am a little worried though about this business of whether there is a body
or not. That seems confusing and possibly means that the client has to
understand the error code to know whether to look for the body or not.

I suggest that we grandfather the existing response codes and specify any
exceptions (304 being one, are there others) and for the rest have the rule
that if Content-Length (or a content-encoding) is specified then there MUST
be a body and it indicates the length of the body. If there is no body the
content length MUST be omitted.

Would it harm things to make this a universal rule?

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

Website: http://hallambaker.com/
Received on Saturday, 22 September 2012 16:10:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC