Re: [squid-users] Caching pages for users without a cookie (guest)

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 16 Jan 2009 15:32:06 +1300

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_at_treenet.co.nz]
> Sent: Wednesday, January 14, 2009 12:03 PM
> To: Elli Albek
> Cc: Amos Jeffries; squid-users_at_squid-cache.org
> Subject: Re: [squid-users] 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
Received on Fri Jan 16 2009 - 02:32:15 MST

This archive was generated by hypermail 2.2.0 : Mon Jan 19 2009 - 12:00:02 MST