On Mar 27, 2008, at 2:02 PM, Henrik Nordstrom wrote:
On Thu, 2008-03-27 at 00:02 -0700, Ric wrote:
So with either authentication method, the only way to cache a split
view and guarantee that authenticated requests don't get the cached
version is via a Vary header. And excluding the authenticated
version
from the cache then just becomes an extra efficiency measure (which
happens automatically with the Authentication header but requires
something like the 'private' token with cookie-authentication).
Yes, but there is some buts...
a) To use the Authenticate header you must configure the resource to
request authentication using 401 responses on unauthenticated requests
which kind of eleminates the possibility of using authentication and
split-view.
Hmm... why is this required? If the request doesn't contain an
Authenticated header, then won't the Vary hash just leave it out? And
once authenticated, isn't the Authenticate header sent with every
request to the same realm from then on?
b) When using cookies each user (even anonymous ones) will most likely
have a unique set of cookies, which means each user visit will send an
unique request which has to go to the web server as it's impossible to
tell how to respond otherwise.
Well sure... Adding Vary:Cookie should probably not be done if your
backend is generating a unique set of cookies for each anonymous
user. So no anonymous tracking via cookies and other such cookie fluff.
c) and in quite many setup using cookies the user even has the same
set
of cookies as anonymous and after logging in, which means that every
request has to go to the backend server even if that exact same cookie
combination has been seen before.
Really? I would think this should not be true if you're doing cookie-
authorization. There has to be a unique cookie to id the authorized
session.
Ric
