- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 19 Sep 2012 20:22:27 -0500
- To: HTTP Working Group <ietf-http-wg@w3.org>
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