> I realize that this is a strong statement, but I believe that I can back > it up. My reasons for not liking this hook at all: > > 1) If I have a page that I have served and it gets put in the cache, > then it will be served out of the quick_handler phase. However, if I > then add or modify a .htaccess file to deny access to that page, then my > changes won't be honored until the page expires from the cache. This is > a security hole, because I don't know of anyway to invalidate cached > pages. (This one if from a conversation with wrowe). [ I guess it > might be possible to clear the cache with a graceful restart. ]
.htaccess applys to things residing in the file system (both physically and logically). quick_handler is by definition a hook that can only serve content out of URL space. mod_cache stores content keyed to the URL. That content can be dynamically generated or it may be a file out of a file system (local or remote). If the content is a file out of the file system, then mod_cache needs to be careful to NOT cache files that have auth or access protections. Make sense so far? Now here is what I hope will convince you that quick_handler is no more a security risk (from an auth/access checking perspective)than having a proxy between you and the server. A proxy should not cache content that requires either access or auth checking. mod_cache uses the exact same algorithms for determining if content should be cached or not, regardless of whether that content is generated locally or not, regardless of whether the content is scraped off the disk or generated dynamically. mod_cache behaves identically to a proxy cache (because it IS a proxy cache). If you do not have a problem with proxy caches, then you should not have a problem with mod_cache's use of the quick_handler hook. I think this explanation covers 2). Your turn. Bill
