W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: updating headers with 304 responses

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 5 Jun 2009 10:25:16 +0200
Message-Id: <12DCEC7D-1317-48B4-AEF7-EA60B92E2039@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Adrien de Croy <adrien@qbik.com>
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.

Received on Friday, 5 June 2009 08:25:53 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC