- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 21 Sep 2012 22:11:47 -0700
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908 that should remove any ambiguity about when content-length is sent. Please review. ....Roy
Received on Saturday, 22 September 2012 05:12:11 UTC