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

On Mar 24, 2008, at 3:22 AM, Henrik Nordstrom wrote:

> On Sun, 2008-03-23 at 01:42 -0700, Ric wrote:
>
>> I guess another alternative to the 'public' token is to instead issue
>> a 'private' token with any cookie-authenticated response that should
>> not be cached. This just moves the default cache strategy for
>> authenticated responses to "cache everything, unless it's private"
>> instead of "do not cache anything, unless it's public". Hmm... this
>> may be a better approach in any case, since it plays better with
>> other
>> shared-caches that might be encountered downstream of my server.
>
> Problem is that as soon as you enable caching of URLs gving split
> views
> shared caches will start caching them, and with the only thing
> differentiating a request for a public copy with a request for a
> private
> copy being the Cookie headers (of which there may be plenty, and often
> changing) you have to say "Vary: Cookie". But since each user will
> most
> likely carry his own set of cookies (and often a changing set) each
> request will be pretty much unique to the shared cache, almost
> eliminating any opportunity for a cache hit.
>
> Regards
> Henrik

Yes, I realize this. Unless we authenticate using one of the
Authenticated header methods, it seems that we have to be careful not
to try caching "split views" in standard proxies. Cookie-
authenticated responses should only be cacheable in public shared
caches if they contain no personalization. The exception being if you
have some other means to control the cache (such as Surrogate-Control)
-- only then can you cache a split view (in your cache only) and
reliably pass all the cookie-authenticated requests (with exceptions
for 'public' responses, assuming this bug is ever fixed).

Ric
Received on Mon Mar 24 2008 - 12:44:12 MDT