- From: Tim Bray <tbray@textuality.com>
- Date: Wed, 19 Sep 2012 19:22:43 -0700
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I had missed this. I just revisited 2616 and unless I misread, this is a new thing. This appears to me to add substantial workload to the server and I don’t comprehend the benefit. Either I missed something, or YAGNI. -T On Wed, Sep 19, 2012 at 6:22 PM, Zhong Yu <zhong.j.yu@gmail.com> 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. 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 02:23:11 UTC