Re: quick_handler hook is completely bogus.

[Graham Leggett <mi...@sharp.fm>]

Eidelman, Brian wrote:

> 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.

The cache already has configuration directives so that you can choose 
which URL spaces are cached, and which are not, and how 
(disk/memory/shared/etc).

> I agree with Graham's notion that any hook designed primarily for caching
> should be moved to after the access control hooks.

I'm now on the fence on this one. The cache is supposed to be layered on 
top of Apache. By moving bits of Apache "in front of" the cache, the 
whole point behind caching is lost. But the point remains that it allows 
it to short circuit the auth stuff, which may not be what people expect 
- but - you're likely to have other caches between browser and Apache 
anyway, so I don't think it will make any difference, the end user will 
still have to force-reload to see the results regardless.

> 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).  

Some permission mechanisms (directory or database for example) are 
expensive too.

However, in order to support caching of different variants depending on 
user, the request will need to be preauthenticated to be safe, otherwise 
a suitably created request could coax a response out of the cache for 
another user.

> Additionally, I'd like to point out that total reliance on cache control
> headers is not a good option.

You find caches in browsers, proxies, and (in Apache's case) webservers, 
and all these are governed by HTTP/1.1. I don't think we should start 
second guessing the protocol - otherwise we start introducing interop 
problems and HTTP goes out the window. I think relying on HTTP/1.1 is 
the only option.

As to applications supporting the cache-control headers, if they don't 
support the headers properly they won't work properly with existing 
software out there anyway, so support is not a problem.

> 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.

Cache-Control: private

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm 
	"There's a moon
					over Bourbon Street
						tonight..."