DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32147>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32147
provide finer grained control over enabling/disabling cache logic
Summary: provide finer grained control over enabling/disabling
cache logic
Product: Apache httpd-2.0
Version: 2.1-HEAD
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: mod_cache
AssignedTo: bugs@httpd.apache.org
ReportedBy: jesses@sportsline.com
This is undoubtably a corner-case, however I've experienced some flexibility
issues configuring mod_cache to work well with a combination of mod_proxy
and mod_rewrite. Specifically, the issue related to the inability
(without resorting to cumbersome URI rewriting kludges) of mod_cache to be
enabled/disabled on more than simply the basis of the leading portion of
a URI path.
Additionally, due to the fact that mod_cache uses the quick_handler hook, it
interrupts (if deciding to return cached content) most down-stream modules so
that they cannot make decisions about caching or non-caching content.
post_read_handler is the obvious exception, however due to the nearly
unconditional way in which mod_cache intercepts requests, it's rather
non-elegant to resort to intercept and avoidance trickery via post_read_handler
algorithms. I do understand that using quick_handler, in the majority
of minimal configuration caching needs, is a performance win.
Certainly, this could be worked around with subrequests, however I would
prefer not to have to deal with the overhead of a subreq on every transaction
(which is what would be necessary in _my_ particular case, others may have
better solutions).
With that being stated, the attached patch to 2.1-HEAD was my solution to
this issue. The following are a list of changes, some of which may be beyond
the scope of what was necessary and violate various development API
integrity rules. If this is the case, I would be happy to remove/alter
certain portions (and I'll mention some discomforts I have below as well).
Changes:
1. Added two optional hooks, cache_check_enabled and cache_check_disabled:
A. cache_check_enabled is run from ap_cache_get_providers in order to
determine if a particular uri (or other condition) is cause to
enable caching. The default handler for this hook implements the
original functionality by iterating the cacheenable list and
adding each entry whose left-most portion of the uri path matches.
B. cache_check_disabled is run from ap_cache_get_provider in order
to dermine if caching should be disabled. The first hook to return
DECLINED causes mod_cache to discontinue trying to find a provider.
Again, the default handler performs the original functionality by
iterating the cachedisable list. In addition, a check_disable hook may
return CACHE_DEFER, which results in mod_cache refusing to return cached
content if in the quick_handler hook. Instead it tries again from a
regular content hook (see below).
2. New optional function: ap_cache_request_enable_provider. Intended
to be used by those who hook check_enabled to add a provider name
("type" seems to be the parlance in mod_cache at that level)
and optional version number to the list of providers that
ap_cache_get_providers() will try to lookup.
Using ap_cache_request_enable_provider is a module's way of telling
mod_cache to attempt caching. The func name is tad cumbersome,
the "request" is only in there to give some indication that it is
a per-request call, not a general-use function for enabling providers.
Perhaps this should be an optional, because it's functionally identical
to a normal API call. If that is the case, then check_enabled and
check_disabled shouldn't be optional hooks either.
3. Added a content handler to mod_cache so that it (or others) can choose,
selectively, to handle a request _after_ other modules have taken
their turn. Particularly useful for mod_rewrite. Additionally, the
request handler must be set to "cache-server", which is done
automatically if a check_disabled handler returns CACHE_DEFER inside
the context of cache_url_handler. mod_rewrite can also enable caching
this way by setting the content handler during a rewrite rule.
In my case, this is useful for enabling both reverse proxy and
caching for requests that meet certain header constraints.
4. Added a new directive "CacheDefer", which when toggled on forces
the above behavior (handling from the content_handler) to be the
default. This was completely arbitrary, however it provided the
functionality I needed and was useful for testing. Obviously,
with the above changes this could be done from anywhere. Not crazy
about the name either, it is .. non-intuitive for those unfamiliar
with the code.
5. The majority of mod_cache.h internals were moved to cache_private.h, due
to the fact that there now exist some intentionally public exports.
The now highly minimalized mod_cache.h added to $top_srcdir/Makefile.in
for the install-include target. All mod_cache related sources that
previously referenced mod_cache.h changed to cache_private.h.
Might need some dependancy fixups, I didn't go that far.
Thank you for your time. I hope this will be of some use. If there are
any questions or requested changes, please feel free to let me know
(or just have bugzilla do it =P)
Jesse Sipprell
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org