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. 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. 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. To get around 'c' one can use "max-age=0, must-revalidate", forcing caches to always query the origin server, but for most setups it's effectively the same as disabling caching entirely. > Of course this still mostly applies to downstream shared caches that > you can't control otherwise. In a reverse-proxy cache under your > control, you can theoretically apply controls other than Vary to allow > caching of anonymous views without contaminating the personalized > authenticated response (as long as you're willing to forgo any > downstream caching). Yes. > You could for example require the 'public' token > before any cached response is delivered to an authenticated request Yes. > (which brings us back full circle to the Squid bug that started this > thread). I wouldn't say bug, but yes. > Or you can add your own cache control extension, say > "anonymous-only", that prevents the cached response from being > delivered to an authenticated request (although the Squid bug stops > this one too). > > Are we in agreement now? :-) Partially, but it's not as simple. For one thing you will also need to fight cache invalidation rules or the cache will automatically expunge the public content when seeing authenticated requests resulting in a different response. But yes, pretty much anything is possible in the reverse proxy setup, if you are willing to bend the setup around your application by tweaking HTTP to your needs rather than making your application use HTTP proper. Regards Henrik
