On Mar 25, 2008, at 3:19 AM, Henrik Nordstrom wrote:
On Mon, 2008-03-24 at 11:44 -0700, Ric wrote:
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.
Even then you have the same problem. A public response is a cache hit
even if the request carries authentication.
Umm... only if it contains a "public" cache control token. That's the
point of the public token. That's why your backend should only add
this token to items that contain no personalization.
But if we're authenticating via cookie instead, then the public token
is sort of pointless and the private token may be more useful.
Cookie-
authenticated responses should only be cacheable in public shared
caches if they contain no personalization.
Which is quite doable if such requests do not have any personal cookie
at all (not even a tracker one), but fails if there is any kind of
session/tracker cookie making each user unique.
I believe this is incorrect. We don't care whether the *request*
contains a personalized cookie; we only care if the subsequent
*response* is personalized. For example, even a personalized response
to an authenticated request may assemble several non-personalized
inline graphics, css, and javascript. All of these responses are
generated from authenticated requests, but only some need to be
"private", the rest can safely be cached.
If there is no user/session/tracking specific cookie on public
requests
then send
Vary: Cookie
Maybe I'm missing something here, but I don't see a need for Vary:
Cookie for non-personalized content (unless one is doing some sort of
cookie-based content negotiation... shudder), and of course we don't
want to cache personalized content.
Ric
