On Sat, 24 Apr 2004, Neil Gunton wrote: > Neil Gunton wrote: > > > > Hi all, > > > > I apologise in advance if this is obvious or otherwise been answered > > elsewhere, but I can't seem to find any reference to it. > > > > I am using Apache 1.3.29 with mod_perl, on Linux 2.4. I am running > > mod_proxy as a caching reverse proxy front end, and mod_perl on the > > backend. This works really well, but I have noticed that mod_proxy does > > not seem to be able to distinguish requests as being different if the > > URLs are the same, but they contain different cookies. I would like to > > be able to enable more personalization on my site, which would best be > > done using cookies. The problem is that when a page has an expiration > > greater than 'now', then any request to the same URL will get the cache > > version, even if the requests have different cookies. Currently I have > > to pass options around as part of the URL in order to make the requests > > look different to mod_proxy. > > > > Am I missing something here? Or, will this be included in either future > > versions of mod_proxy or the equivalent module in Apache 2.x? Any > > insights greatly appreciated. > > I should perhaps make clear that I do have cookies working through the > proxy just fine, for pages that are set to be 'no-cache'. So this isn't > an issue with the proxy being able to pass cookies to/from the backend > and browser (which I think I have seen mentioned before as a bugfix), > but rather with mod_proxy simply being able to distinguish otherwise > identical URL requests that have different cookies, and cache those as > different requests. > > So for example, the request "GET /somedir/somepage.html?xxx=yyy" passed > with a cookie that value 'pics=small' should be seen as different from > another identical request, but with cookie value 'pics=large'. Currently > my tests indicate that mod_proxy returns the same cached page for each > request. > > I assume that mod_proxy only checks the actual request string, and not > the HTTP header which contains the cookie. > > Obviously, under this scheme, if you were using cookies to track > sessions then all requests would get passed to the backend server - so, > perhaps it would be a nice additional feature to be able to configure, > through httpd.conf, how mod_proxy (or its successor) pays attention to > cookies. For example, you might say something to the effect of "ignore > this cookie" or "differentiate requests using this cookie". Then we > could have sitewide options like e.g. 'pics' (to set what size pictures > are shown), and this could be used to distinguish cached pages, but > other cookies might be ignored on some pages. This would allow for more > flexibility, with some cached pages being "sensitive" to cookies, while > others are not. An obvious way this would be useful is in the use of > login cookies. These will be passed in by the browser for every page on > the site, but this doesn't mean we want to distinguish cached pages > based on it for every page. Some user-specific pages would have > 'no-cache' set, while other pages could be set to ignore this login > cookie, thus gaining the benefits of the proxy caching. This would be > useful for pages that have no user-specific or personalizable aspects - > they could be cached regardless of who is logged in. > > Sorry if this wasn't clear from the original post, just wanted to > clarify and expand... any advice on this would be VERY welcomed, since > my options with personalization are currently rather limited. > > Also, if this is actually addressed to the wrong list for some reason > then a pointer would be much appreciated...
mod_accel ( http://sysoev.ru/en/ ) allows to take cookies into account while caching: AccelCacheCookie some_cookie_name another_cookie_name You can set it on per-location basis. Besides, my upcoming light-weight http and reverse proxy server nginx will allow to do it too. Igor Sysoev http://sysoev.ru/en/