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

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.

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

Yes.

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

The cache cares. It needs to be able to identify what to use for this
request.

> For example, even a personalized response
> to an authenticated request may assemble several non-personalized
> inline graphics, css, and javascript.

Yes, but each of those is individual URLs and handled separate. If
non-personal then make them public.

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

No, but you want to provide a split-view on the same URL providing both
a public copy for anonymous guests and a personalized copy for
authenticated users.

Regards
Henrik
Received on Wed Mar 26 2008 - 16:07:20 MDT