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
