Re: updating headers with 304 responses

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