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

From: Jason Noble <jason_at_linuxbox.com>
Date: Tue, 16 Jun 2009 10:13:10 -0400

You're right, looks like I read that section too quickly. After reading
the RFC more carefully, it appears that the case I'm having issues with
is undefined. The closest thing I can find is 13.3.4:

An HTTP/1.1 caching proxy, upon receiving a conditional request that
   includes both a Last-Modified date and one or more entity tags as
   cache validators, MUST NOT return a locally cached response to the
   client unless that cached response is consistent with all of the
   conditional header fields in the request.

But I'm actually interested in the case where the caching proxy receives
a non-conditional request. The current behavior of Squid is to return a
cached entity. It seems to me that not returning cached entries that
include conditional header fields would be more consistent with the
behavior of "not returning a locally cached response to the client
unless that cached response is consistent with all of the conditional
header fields in the request" (i.e. the absence of conditional header
fields does not match the presence of one or more conditional header
fields.) If this case is indeed defined in the RFC, I'd be interested
to know where.

Thanks,
Jason

Mark Nottingham wrote:
> Selecting request headers are specified by Vary; If-None-Match is a
> conditional request header.
>
> Cheers,
>
>
> On 16/06/2009, at 12:44 AM, Jason Noble wrote:
>
>> 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
>>>
>>>
>
> --
> Mark Nottingham mnot_at_yahoo-inc.com
>
>
Received on Tue Jun 16 2009 - 14:13:22 MDT

This archive was generated by hypermail 2.2.0 : Sat Jun 27 2009 - 12:00:04 MDT