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

On 07/01/2009 02:19 PM, Jason Noble wrote:
>>
>> but it feels like you are trying to accomplish something very
>> unusual/weird
> Perhaps some more background information is in order here. What we are
> trying to accomplish is acceleration on a Zope/Plone CMS. The CacheFu
> product is primarily responsible for setting cache headers and issuing
> purge requests to Squid. CacheFu uses the ETag mechanism for marking
> variations of a cached entity based on logged in user and some other
> preferences. We would like to cache anonymous and authenticated
> versions of pages in Squid. The big problem we are facing is that if an
> authenticated user visits a URL, Squid will cache that page with the
> appropriate ETag. A subsequent request by an anonymous user will return
> the cached version of that page -- this may reveal information that
> should not be publicly available. If Squid's behavior were modified in
> the manner described, the anonymous request would not match the cached
> entity and would therefore result in a request to Zope/Plone which would
> serve the anonymous version of the page, which Squid would cache.

Do HTTP requests from authenticated users differ from unauthenticated
requests in your environment?

If they differ, can you add an appropriate Vary header to origin server
responses so that only authenticated users get authenticated cached
content? If they do not differ, can you make them different by adding a
custom header to authenticated requests?

Thank you,

Alex.

> This seems like a typical model for modern web applications. I now see
> from looking at the RFC that it does not support this type of behavior.
> In light of this, the patch should be extended to make the behavior a
> configurable option. It seems that others would be interested in this
> configuration as well.
>
> Alex Rousskov wrote:
>> On 06/16/2009 08:13 AM, Jason Noble wrote:
>>
>>> 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.
>>>
>>
>> You are applying requirements for a "conditional request [field]" to an
>> unconditional request and/or to a stored response. They are not
>> applicable. There is simply no such thing as a "conditional response
>> field".
>>
>> You can sort of think of a Vary response field to be "conditional"
>> (which is what Mark have noted) but, in your case, there is no Vary,
>> right? Perhaps the server should add Vary for its specific application,
>> but it feels like you are trying to accomplish something very
>> unusual/weird.
>>
>> Why do you want Squid to ignore cached entities with ETags if a client
>> does not use ETags or does not have ETags?
>>
>> Thank you,
>>
>> Alex.
>>
>>
>>
>>> 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 Wed Jul 01 2009 - 20:59:18 MDT