On Wed, Aug 17, 2005 at 02:20:59AM +0100, Colm MacCarthaigh wrote: > On Tue, Aug 16, 2005 at 06:02:04PM -0700, Justin Erenkrantz wrote: > > The quick handler runs well before any knowledge is available about the > > backend (dir/file). The only thing you know is the URI path: > > unsurprisingly, > > this is all that CacheEnable and CacheDisable can reasonably work with. > > It's not the only thing, we also have the Cache provider itself. > > If that lookup is quick enough (it certainly would be for say > mod_mem_cache) that's how you determine if it's cached. > > From experience with mod_disk_cache, I don't it's hit as all that > expensive either, I run millions of requests through "CacheEnable disk > /" per day without problem, but I still have to concede it is going to > be slower than a few strcmp's.
Oh, so you mean to see if previous requests have cached it? But, again, that doesn't show you a 'negative' (non-cacheable) response. And, we already have to do this - so I'm not sure what you mean here. > By the time the cache_save_filter is run, the directory walks have > happened, so deciding cachability there is trivial. Right. But, that's not telling us anything about whether its cacheable or not. > > The only way to resolve this is to do the directory walks and file > > resolution; > > but that is *very* expensive to do per request. -- justin > > My changes didn't need this at all. Oh. *light bulb* Let me see if I understand what you are proposing: only exclude saving the request by redoing the configuration check in cache_save_filter. We still have to go through the entire process as if we were to cache the request; but we'd block it at the last second from actually being saved in the filter. Yah, I guess that could work. -- justin
