I agree with everything that Brian said, and he put it far better than I could have. I would be MUCH happier with the quick_handler phase if it occurred after the AAA phases.
Potentially, this could be achieved, and the performance could be improved by simply having the cache module register a map_to_storage function, which checked to see if the page was in the cache. If it is, then no other map_to_storage function is required (assuming enough state is saved in the cache to re-authenticate the request). If it isn't, then the server moves on to the next function. This has the advantage of being secure, and it also removes the biggest performance problem, the directory and location walks. Ryan ---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: Eidelman, Brian [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 31, 2002 8:01 AM > To: '[EMAIL PROTECTED]' > Subject: RE: quick_handler hook is completely bogus. > > Hi All, > > As an access control module developer I feel compelled to weigh in here. > > First, I would like to point out that you cannot determine whether a page > was password protected based on the Apache configuration files including > .htaccess. Modules such as the one we develop, which is widely deployed, > plug into the access hook and use more robust notions of access policies. > > The only safe way you can determine what content is safe to cache is by > having a robust set of configurable rules in your caching module (or > proxy) > that allows a site administrator to set rules that determine what is safe > to > cache. These rules can be as simple as "cache these URLS" or as complex > as > "cache all URLS that end with .gif when no cookies are sent inbound or set > outbound and when there is no cache control header telling us not to > cache." > > The caching done in mod_cache and in reverse proxy caches are different > from > browser caches and forward proxy caches from an access control point of > view > in that it is within the scope and responsibility of the enterprise that > owns the content being cached. To put it another way, mod_cache and > rproxy > caches are responding to real requests made back to the server where as > browser caches and forward proxy caches are not. > > I agree with Graham's notion that any hook designed primarily for caching > should be moved to after the access control hooks. I think the direct > performance impact will be minimal and easily made up for by the fact that > you will be able to cache more content since you will no longer be > constrained by whether or not the content is protected (only by whether or > not it is dynamic for each user/request). > > Additionally, I'd like to point out that total reliance on cache control > headers is not a good option. Unfortunately, the reality is that most > dynamic web applications are unaware of these headers and incapable of > setting them or honoring them. At the same time, an access control module > may not want to set a do not cache header on every request because it > might > be acceptable (as described above) for a browser cache to cache a piece of > content but not for mod_cache or a reverse proxy cache. Enterprises must > strike a delicate balance here. This balance is usually reached by using > cache control headers to communicate with the end user and use other > intelligent cooperation for the enterprises internal caching mechanisms. > > Stepping back a little to discuss the hook in general rather than > mod_cache, > I agree strongly with Ryan that it is dangerous and to some extent > conceptually flawed. A well designed API that uses callbacks should allow > people to plug in to do the work that was designed to happen in that hook > without having to worry too much about whether or not some other module > that > plugs in somewhere else is going to circumvent that hook. Even if the > quick_handler hook is being used appropriately and safely by one module, > that does not justify the power given to it.
