Elli Albek wrote:
Amos what about this:
I add a squid URL rewrite rule, that whenever the cookie exists, append a
meaningless query parameter to the URL.
The origin server will ignore this parameter, and squid will not try to
cache the URL since it has a query parameter.
Example: A logged in user goes to the page /san-francisco, it will be
rewritten to /san-francisco?foo=bar
But for guest it will not be rewritten, so squid will cache the results
based on the reply headers for guest.
Does that sound like a solution?
Yes, with the added parameter. The page is no longer at the same URI and
will not obsolete the guest page.
You may as well form a dummy sub-domain where:
only people with the cookie can load things.
people without cookie get re-directed to same URI-path at main domain
and vice-versa
That way not just your Squid but all proxies can have expected behaviour.
But why are you evading adding a Vary: header?
Amos
E
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Wednesday, January 14, 2009 12:03 PM
To: Elli Albek
Cc: Amos Jeffries; squid-users@xxxxxxxxxxxxxxx
Subject: Re: Caching pages for users without a cookie (guest)
The thing is that squid should cache for some users and not for other
users.
Lets say we have two users, me (logged in) and guest (not logged in).
Both ask for the same page with this sequence:
1. guest
2. me
3. guest
Then we want:
1. guest: get page from origin and cache the response (cache miss).
2. me: get page from origin again, do not cache the response (cache
bypassed).
3. guest: get page from cache, do not go to origin server (cache hit).
Response 1 has Expires and max-age headers, but squid should NOT honor
them in request 2 and should honor them in request 3. This decision is
based on the cookie. So the cookie acl will override the expected HTTP
based behaviour.
I think a regular expression on the cookie can determine if squid should
go to the origin server (regardless of what is in the cache) or act as
normal (cache based on HTTP headers). This is done per request. The
response headers can be used only in request 3, but they should be ignored
in request 2.
You mentioned Expires and Cache-Control, earlier. I just had a thought
that Vary: and ETag: headers may need to be set for these pages.
Squid will cache (1) then if (2) looks identical but has auth headers it
will purge the cached copy (page has apparently become private/authed) and
have to fetch a new one for (3).
With Vary: something (I'm not sure if Cookie: or *-Auth* values are best)
Squid may be expected to cache the copies differently.
To test whether this is right try this sequence:
(1), (guest), (2), (3), (guest)
If it is a vary issues I would expect the marked (guest) to be HIT but (3)
to be MISS despite the earlier (1).
Amos
--
Please be using
Current Stable Squid 2.7.STABLE5 or 3.0.STABLE11
Current Beta Squid 3.1.0.3
