Content-Length and 304

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. But now it becomes non-compliant under the new spec.

Is this new requirement really necessary? Who would benefit from it?

According to the reasoning of

====
http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-20#section-4.1
4.1. 304 Not Modified
Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, the
response SHOULD NOT include representation metadata other than the
above listed fields
====

we SHOULD NOT include Content-Length in 304 responses either.

I think the meaning of Content-Length is confusing enough, in the case
of 204/304 response, it's better to require that
1. server SHOULD NOT set Content-Length
2. client MUST ignore Content-Length

Zhong Yu

Received on Thursday, 20 September 2012 01:22:54 UTC