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

ons 2009-07-01 klockan 16:45 -0400 skrev Jason Noble:
> As mentioned in my previous e-mail, we are working to implement caching
> of anonymous/authenticated versions of pages in a Zope/Plone
> environment.

Ah..

As you probably know by now HTTP cache model isn't really designed for
that.. content are meant to be either anonymous or restricted, not
both.. Cookie based authentication and caching do not work well
together.

> 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.

I think you misunderstood me there. In both approaches mentioned in the
message above Vary is meant to be used.

> 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.

The first part of that response talks about a Squid implementation
"bug", outside of RFC2616 where you can use the Vary header as a kind of
object version tag. Each time Squid sees a new (cachable) Vary header
content old cached entries for that URL will get lost as the Vary index
key function gets changed as it's based on last known Vary header for
the resource.

Second part mentions that Vary support in Squid is a lot better with the
ETag support, then available as a patch and nowdays a standard part of
Squid-2 (but not yet Squid-3).

What I meant was that you should do this combination:

* Send appropriate ETag values in the responses
* Handle If-None-Match
* In the Vary header, apart from the headers the response varies on
(i.e. Accept-Encoding, Cookie), also include a document version
identifier as a custom header such as X-Change-NNNN where the first
version of the object will have X-Change-1, second version X-Change-2
etc... The dummy version/change header as such do not need to be present
in the response, just mentioned in Vary.

The first two optimizes the cache use, and if done right makes life
easier for your server as well.

The second makes sure that once Squid learns that one variant of the
object have changed it will loose track of the other cached variants
(cache misses on next request until cached again). But please note that
this is actually an implementation bug/shortcoming and may change in
future..

But either way it won't do very well, unless your Cookie based
authentication is the only cookies you use AND you make sure to clear
the cookies on anonymous users AND non-anonymous content is marked
non-cachable.

Regards
Henrik
Received on Wed Jul 01 2009 - 21:46:56 MDT