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

Re: Content-Length and 304

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 21 Sep 2012 22:11:47 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <89D241F8-E5B2-45BC-9056-CA87DE291836@gbiv.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
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


that should remove any ambiguity about when content-length is
sent.  Please review.

Received on Saturday, 22 September 2012 05:12:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC