AW: AW: [squid-users] Mixing cached and non-cached access of same URLs by session-id

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
Received on Tue Sep 15 2009 - 15:02:56 MDT