Re: Problem with cached entries w/ETag and request without If-None-Match header

From RFC 2616 13.6:
...
When the cache receives a subsequent request whose Request-URI specifies one or
more cache entries including a Vary header field, the cache MUST NOT use such a
cache entry to construct a response to the new request unless all of the
selecting request-headers present in the new request match the corresponding
stored request-headers in the original request.
...

For the case in question, all selecting request headers do not match the
stored request headers. Therefore, the cache must not use the stored
entry to construct a response.

--Jason

Mark Nottingham wrote:
> What requirement in RFC2616 does this violate?
>
> On 13/06/2009, at 3:02 AM, Jason Noble wrote:
>
>> I recently ran into a bug on Squid 2.7 regarding cached content with
>> ETags. Currently, if all cached entries for a URL include ETags, and
>> a request is received for said URL with no If-None-Match header,
>> Squid will serve a cached entry. This behavior does not follow RFC
>> 2616. I have attached a patch that prevents Squid from serving the
>> cached entries in said case here:
>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2677
>>
>> I would appreciate any feedback regarding this patch.
>>
>> Thanks,
>> Jason
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>
Received on Mon Jun 15 2009 - 14:44:50 MDT