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

On Mar 25, 2008, at 3:19 AM, Henrik Nordstrom wrote:

> On Mon, 2008-03-24 at 11:44 -0700, Ric wrote:
>> 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.
>
> 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.

But if we're authenticating via cookie instead, then the public token
is sort of pointless and the private token may be more useful.

>> Cookie-
>> authenticated responses should only be cacheable in public shared
>> caches if they contain no personalization.
>
> Which is quite doable if such requests do not have any personal cookie
> at all (not even a tracker one), but fails if there is any kind of
> session/tracker cookie making each user unique.

I believe this is incorrect. We don't care whether the *request*
contains a personalized cookie; we only care if the subsequent
*response* is personalized. For example, even a personalized response
to an authenticated request may assemble several non-personalized
inline graphics, css, and javascript. All of these responses are
generated from authenticated requests, but only some need to be
"private", the rest can safely be cached.

> If there is no user/session/tracking specific cookie on public
> requests
> then send
>
> Vary: Cookie

Maybe I'm missing something here, but I don't see a need for Vary:
Cookie for non-personalized content (unless one is doing some sort of
cookie-based content negotiation... shudder), and of course we don't
want to cache personalized content.

Ric
Received on Tue Mar 25 2008 - 19:13:22 MDT