On Mar 24, 2008, at 3:22 AM, Henrik Nordstrom wrote:
On Sun, 2008-03-23 at 01:42 -0700, Ric wrote:
I guess another alternative to the 'public' token is to instead issue
a 'private' token with any cookie-authenticated response that should
not be cached. This just moves the default cache strategy for
authenticated responses to "cache everything, unless it's private"
instead of "do not cache anything, unless it's public". Hmm... this
may be a better approach in any case, since it plays better with
other
shared-caches that might be encountered downstream of my server.
Problem is that as soon as you enable caching of URLs gving split
views
shared caches will start caching them, and with the only thing
differentiating a request for a public copy with a request for a
private
copy being the Cookie headers (of which there may be plenty, and often
changing) you have to say "Vary: Cookie". But since each user will
most
likely carry his own set of cookies (and often a changing set) each
request will be pretty much unique to the shared cache, almost
eliminating any opportunity for a cache hit.
Regards
Henrik
Yes, I realize this. Unless we authenticate using one of the
Authenticated header methods, it seems that we have to be careful not
to try caching "split views" in standard proxies. Cookie-
authenticated responses should only be cacheable in public shared
caches if they contain no personalization. The exception being if you
have some other means to control the cache (such as Surrogate-Control)
-- only then can you cache a split view (in your cache only) and
reliably pass all the cookie-authenticated requests (with exceptions
for 'public' responses, assuming this bug is ever fixed).
Ric
