tis 2009-09-15 klockan 17:02 +0200 skrev Schermuly-Koch, Achim: > Ok. I have implemented som code, that adds an ETag header dependung of the requested URI and the sessionId. Unfortunately it does not work. The more i am thinking about it the more i am coming to the point, that it cannot work with ETags (pleas correct me if i am mistaken). Almost all users get a cached unpersonalized response. You also have to use Vary. > User A requests "/index.jsp" [ETag: "<some public hash>"] it is cached within the squid. > User B requests "/index.jsp" "/index.jsp" is found on the squid and returned directly from cache using the cached [ETag: "XYZ"] Subject to your Vary settings. > Bottomline is, that the ETag-based solution does not work, since ETags are a response header concept, whereas content- > negotiation (this is what they call it in the specs) is a request header based concept. The only request header > available for negotiation is the cookie header. I am not getting the point why that is such a "very bad idea (tm)"? No, the bottom line is that using the same URL for personalized and anonymous content do not work if rendered by the web server, as HTTP do not support such split in a reasonable manner. It's not really about ETag, but about how Vary work. Vary indicates which request headers the response is dependent on (i.e. Cookie in your case), but Cookie is kind of a kitchen sink with lots of crap getting into it making the variance in Cookie headers large even for anonymous access on most sites. Caching of urls like this can only work if you design the site such that only authenticated sessions have some form of cookie and anonymous / logged out users have absolutely no cookies at all (or at least none which varies with the user, to tracking cookies, no stale session cookies) The better way of doing this is to make use of the DOM to have the browser dynamically add the personalized content, keeping the basic HTTP content exchanges the same. Regards Henrik
