- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 20 Sep 2012 07:11:47 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi, On Wed, Sep 19, 2012 at 08:22:27PM -0500, 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. But now it becomes non-compliant under the new spec. > > Is this new requirement really necessary? Who would benefit from it? I remind an old application I saw about 10 years ago which fell into this trap of sending "Content-Length: 0" along with 304 responses. The result was blank pages for clients fetching these responses from a cache (apache 1.3), because the cache used the headers fetched from the response to update the ones it had in the cache and subsequently delivered empty objects only. I think that *all* header fields must be sent with a 304 as they would have been with the real response, it avoids such trouble. > 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 It's true that this part is confusing, we all have an exception for this in client code to ignore the length (suggestion #2 above). However, we also know that at least some clients break if we send a wrong content length, so it should probably be the same if we don't send any. In my opinion, better leave this untouched to remain compatible with what is deployed. If you think that some points are still confusing in the spec, maybe we should try to improve the wording to remove any confusion. Regards, Willy
Received on Thursday, 20 September 2012 05:12:20 UTC