httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: RFC: can I make mod_cache per-dir?
Date Wed, 17 Aug 2005 01:45:45 GMT
On Wed, Aug 17, 2005 at 02:33:30AM +0100, Colm MacCarthaigh wrote:
> > Why would the system trigger a match then?  The configuration should block the
> > requests from being processed.
> Because it would be basing its decision to serve a cached entity
> entirely based on that entity being in the cache. 

See below.

> > > 	# Don't cache these files at all
> > >         <LocationMatch ~/foo/*.txt$>
> > > 	    CacheContent disk off
> > > 	</LocationMatch>
> > 
> > Should that be 'off' or 'none' or something else?  What's disk doing here?
> In my implementation, it was removing disk from the list of caching
> providers for that context :)

The correct thing would be to clear the provider hash for that location.

> I don't think it's that easy to achieve without triggering Graham's very
> valid -1. The decision on whether to serve from the cache would be based
> entirely on entities being in the cache, which is non-intuitive to
> administrators.

Oh.  Ergh.  I didn't catch that part of your proposal.  Yah, -1 too.

> There is a another way of doing it though, which would be to allow
> CacheEnable directives on a per-dir basis but only within <Location>
> blocks. 
> So;
> 	<Location "/foo">
> 		CacheEnable disk
> 	</Location>
> might be equivalent to "CacheEnable disk /foo". It would be trivial to
> make this work as-is, but seems fairly pointless. Location-based
> application can be done already.

That would be an improvement over what we have today.

However, I wonder if we can store some information in our cache that can
provide enough information for the check (i.e. done with directory/file).

A thought: record the fact that this particular cache entry was originated
through a directory check - this can also *only* happen when mod_cache is
fronting a local origin server (nowhere else would Directory come into play).
Under what I've deduced from your previous emails, we know this because we'd
have to delay our cacheablity config check until cache_save_filter.  So, if
this bit is set, then we know we have to wait for the directory/location walk
to run again before we can 'approve' serving the cached response.  (Or, we
could also try to run the directory walk ourselves in the cache handler.)

Yet, there is a *possibility* that something could switch from a Location to a
Directory (i.e. switch from a scenario where we could solely rely upon the
configuration to where a directory now controls the cacheability: hence we
need the dir walk).  Not sure what we should do there.

We'd certainly sacrifice some speed under these circumstances; but it'd
perhaps be better than nothing and would avoid the possibility where we serve
content that is now excluded.  -- justin

View raw message