Sorry to bother you all, and first: thanks for building such a great product!
My question is related to the patch suggested by Paul Quenna (in 2005) where mod_cache is allowed to be configured to run as a "normal" handler instead of always as a "quick handler". The initial patch and related discussion is here: http://thread.gmane.org/gmane.comp.apache.devel/20314 with a follow-up related to bug 36937 here: http://thread.gmane.org/gmane.comp.apache.devel/22676/focus=22679 Originally, the patch was voted down, and I see the rationale for not including it without a clear use case. But in our setting, it would be of high value to get it into the official release. I have outlined our syste below, in the hope that someone can decide whether we are within the planned scope of mod_cache or not. ** Motivation Our server setup is as follows: * PROXY: Apache 2.2.11 with mod_cache and mod_proxy. * APPSERVER: A JavaEE application server running a Java-based CMS. The main part of the motivation for PROXY is to reduce the need to regenerate content by the heavyweight CMS-processes. Security is also handled by PROXY, where we use Sun Access Manager to enforce policy-based authentication. This is provided by running a "policy agent" which is loaded as an Apache-module. Policies are specified on quite broad level, e.g. "all users that are marked 'internal' in our LDAP can see everything, others can see nothing". When PROXY receives a request for a non-cached URL, the agent first authenticates the user (either by using buil-in SSO modules or through password authentication), and then decides whether the user is allowed to access this URL. If so, the request is forwarded from PROXY to APPSERVER and can be served without further validation. The challenge is that since we use mod_cache on PROXY, requests that can be served from cache are returned directly to the user - without ever being seen by the policy agent. This is of course as expected, since mod_cache uses a special "quick handler" in Apache's request chain, allowing requests for cached objects to be served with minimal processing overhead. But as noted above, it is necessary for us to protect the cache against unauthorized users. Our current workaround is to run two reverse proxy-instances, one which provides authentication (on port 80) and another providing cache (on port 7920, which is only accessible from within PROXY). A request then first hits the authentication proxy on port 80, and if valid, is forwarded to the caching proxy on local port 7920. This works, but it feels somewhat suboptimal, and we would much prefer to be able to use one instance to serve both purposes. Thank you in advance for any assistance! -- Kind regards, Jon Grov