Search squid archive

Re: bug? (was "cache deny and the 'public' token")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux