Hi, i am still fighting with my personal/private caching problem.
>>>> We are using squid as a reverse-proxy cache to speed up our website.
>>>> A large area of the website is public. But there is also a
>>>> personalized area. If a user logs into his personal site, we maintain
>>>> a session for the user (using standard tomcat features jsession-id
>>>> cookie with optional url-rewriting).
[...]
>>> The HTTP way to achieve similar is to add "ETag:" header with some hash
>>> of the page content in it. So each unique copy of the page is stored
>>> separately. The personalized pages get "Cache-Control: private" added as
>>> well so that whole request get discarded.
[...]
>> The ETag would be generated by the webserver. A public page (/index.jsp)
>> would have _one_ ETag if rendered without and a different unique ETag for
>> each request (to the same /index.jsp) with a session-cookie. The cache
>> for the publicly cached page would be left untouched, if the response
>> bears a "Cache-Control: private" header but with a different ETag. That
>> implies, the cache is flushed when the webserver responds, not when the
>> client requests.
[...]
>ETag is meant to identify a unique copy of each object at a URL. The
>compressed vs non-compressed version and the personalized vs
>non-personalized versions.
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.
Here is what is happening (presumably):
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"]
User C logs into the system. He is assigned a sessionid.
User C requests "/index.jsp". Two things might happen:
1. If user C was the first to request the resource the proper personalized ETag would have
been rendered by the app-server; the cache-control header would would have been set to "private"
so no private data would be stored and leak the ETag would be [ETag: "<sessionid based private hash>"].
2. Unfortunately the request is already cached upon the request of user A. And this is what is returned
to user C: "/index.jsp" identified by [ETag: "<some public hash>"].
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)"?
Comments?
Ragards achim
