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: [email protected] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
