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

On Mar 27, 2008, at 2:02 PM, Henrik Nordstrom wrote:

> On Thu, 2008-03-27 at 00:02 -0700, Ric wrote:
>
>> 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).
>
> Yes, but there is some buts...
>
> a) To use the Authenticate header you must configure the resource to
> request authentication using 401 responses on unauthenticated requests
> which kind of eleminates the possibility of using authentication and
> split-view.

Hmm... why is this required? If the request doesn't contain an
Authenticated header, then won't the Vary hash just leave it out? And
once authenticated, isn't the Authenticate header sent with every
request to the same realm from then on?

> b) When using cookies each user (even anonymous ones) will most likely
> have a unique set of cookies, which means each user visit will send an
> unique request which has to go to the web server as it's impossible to
> tell how to respond otherwise.

Well sure... Adding Vary:Cookie should probably not be done if your
backend is generating a unique set of cookies for each anonymous
user. So no anonymous tracking via cookies and other such cookie fluff.

> c) and in quite many setup using cookies the user even has the same
> set
> of cookies as anonymous and after logging in, which means that every
> request has to go to the backend server even if that exact same cookie
> combination has been seen before.

Really? I would think this should not be true if you're doing cookie-
authorization. There has to be a unique cookie to id the authorized
session.

Ric
Received on Thu Mar 27 2008 - 17:00:29 MDT