You mean adding Set-Cookie to the vary header? Something like: Vary: Accept-Encoding Set-Cookie The reason is that since all the cookies are lumped into one request header, you have there analytics tracking cookies which are different for every browser client. So the cache key is going to be unique per client since the request cookies are unique per client. This is in addition to a few of our cookies that can create thousands of combinations. Good point about other proxies between squid and the client. I did not think about it. Maybe its best if squid does not pass on the validators to the client, so the next proxies just pass through. So the validators in that case are just for app server to squid communications. E -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Thursday, January 15, 2009 6:32 PM To: Elli Albek Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: Caching pages for users without a cookie (guest) 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
