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

As mentioned in my previous e-mail, we are working to implement caching
of anonymous/authenticated versions of pages in a Zope/Plone
environment. In a discussion in 2005 revolving around this same
subject, you recommended to a user that they use ETags instead of Vary:
Cookie in this situation (
http://www.eu.squid-cache.org/mail-archive/squid-users/200510/0491.html
) due to purging issues with Vary. We have indeed gone the
ETag/If-None-Match route, but are experiencing problems this way as
well. It appears to be the case that Squid (and indeed RFC2616)
currently provide no way to handle this case. The point of this patch
is to provide a mechanism for Squid support such behavior. If there is
a way to achieve this behavior without modification to Squid, or the
client we would be very interested in that technique.

Thanks,
Jason

Henrik Nordstrom wrote:
> fre 2009-06-12 klockan 13:02 -0400 skrev Jason Noble:
>
>> 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.
>>
>
> As others have already pointed out it's plain wrong.
>
> Please read "RFC2616 13.6 Caching Negotiated Responses" again for more
> details on how this works in HTTP. It's a quite simple and effective
> scheme when used right.
>
> In short
>
> Selecting request headers (as indicated by Vary) select which response
> may be returned in response to the request. If there is multiple
> matching responses then the most recent among them should be used.
>
> Conditional request headers determine if that response is to be a 200,
> 304 or in case of origin servers only 412.
>
> An unconditional request is just that, and will always respond with the
> matching 200 response.
>
> Clients can not select which response to return based on etag, only by
> using negotiation request headers as indicated by Vary, such as Accept,
> Accept-Language, Accept-Encoding, Cookie etc..
>
> Regards
> Henrik
>
>
Received on Wed Jul 01 2009 - 20:45:18 MDT