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

On Mar 26, 2008, at 3:06 PM, Henrik Nordstrom wrote:

> On Tue, 2008-03-25 at 18:13 -0700, Ric wrote:
>>> Even then you have the same problem. A public response is a cache
>>> hit
>>> even if the request carries authentication.
>>
>>
>> Umm... only if it contains a "public" cache control token. That's
>> the
>> point of the public token. That's why your backend should only add
>> this token to items that contain no personalization.
>
> Not what I meant.
>
> What I meant was
>
> 1. A unauthenticated request for the resource, causing a public
> version
> to get cached.
>
> 2. Authenticated request. This will see a cache hit to the previous
> cached public response.

Ahh okay... I think I understand what you mean now.

An authenticated request (even one authenticated via Authentication
headers) could be served a response from cache even if the cached
version lacks a 'public' token. So caching a split view is
problematic even when authenticating via Authentication headers. This
is of course the same situation as with cookie-authenticated requests.

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

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). You could for example require the 'public' token
before any cached response is delivered to an authenticated request
(which brings us back full circle to the Squid bug that started this
thread). 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? :-)

Ric
Received on Thu Mar 27 2008 - 01:02:26 MDT