Re: [squid-users] bug? (was "cache deny and the 'public' token")

On Thu, 2008-03-27 at 00:02 -0700, Ric wrote:

> So with either authentication method, the only way to cache a split
> view and guarantee that authenticated requests don't get the cached
> version is via a Vary header. And excluding the authenticated version
> from the cache then just becomes an extra efficiency measure (which
> happens automatically with the Authentication header but requires
> something like the 'private' token with cookie-authentication).

Yes, but there is some buts...

a) To use the Authenticate header you must configure the resource to
request authentication using 401 responses on unauthenticated requests
which kind of eleminates the possibility of using authentication and
split-view.

b) When using cookies each user (even anonymous ones) will most likely
have a unique set of cookies, which means each user visit will send an
unique request which has to go to the web server as it's impossible to
tell how to respond otherwise.

c) and in quite many setup using cookies the user even has the same set
of cookies as anonymous and after logging in, which means that every
request has to go to the backend server even if that exact same cookie
combination has been seen before.

To get around 'c' one can use "max-age=0, must-revalidate", forcing
caches to always query the origin server, but for most setups it's
effectively the same as disabling caching entirely.

> Of course this still mostly applies to downstream shared caches that
> you can't control otherwise. In a reverse-proxy cache under your
> control, you can theoretically apply controls other than Vary to allow
> caching of anonymous views without contaminating the personalized
> authenticated response (as long as you're willing to forgo any
> downstream caching).

Yes.

> You could for example require the 'public' token
> before any cached response is delivered to an authenticated request

Yes.

> (which brings us back full circle to the Squid bug that started this
> thread).

I wouldn't say bug, but yes.

> Or you can add your own cache control extension, say
> "anonymous-only", that prevents the cached response from being
> delivered to an authenticated request (although the Squid bug stops
> this one too).
>
> Are we in agreement now? :-)

Partially, but it's not as simple.

For one thing you will also need to fight cache invalidation rules or
the cache will automatically expunge the public content when seeing
authenticated requests resulting in a different response.

But yes, pretty much anything is possible in the reverse proxy setup, if
you are willing to bend the setup around your application by tweaking
HTTP to your needs rather than making your application use HTTP proper.

Regards
Henrik
Received on Thu Mar 27 2008 - 15:03:25 MDT