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
Received on Tue Sep 15 2009 - 18:38:20 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 16 2009 - 12:00:03 MDT