- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 5 Jun 2009 10:25:16 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Jun 5, 2009, at 9:12 AM, Adrien de Croy wrote: > There's a requirement in RFC2616 to use headers included in 304 > responses to either invalidate or update cached entries. > > Specifically it looks like if the 304 response returns a different > value to what is stored, for any of > > Content-Length > Content-MD5 > Last-Modified > ETag > > Then the cache must invalidate the stored entry. This is fine, > until you hit IIS which seems to be returning a Content-Length: 0 > in all 304 responses. > > I guess that since the 304 message has no entity body, the Content- > Length of 0 is understandable, if not maybe misguided? Or is it > correct? It is a bug in IIS. > Is it legal in a 304 response to include a Content-Length value > other than 0? It's not like a HEAD command, this is a 304 response > to a conditional GET. Additionally 304 responses are prohibited > from having an entity body. > > The rules for message length imply that with a 304 response, the > Content-Length header does not specify the message length. So it's > just payload. > > So should I assume that this is just a bug on the part of this IIS > server? What do others do? It causes problems obviously to > invalidate the cache entry because of this. Just workaround it based on the Server header. ....Roy
Received on Friday, 5 June 2009 08:25:53 UTC