httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: RFC: can I make mod_cache per-dir?
Date Wed, 17 Aug 2005 01:33:30 GMT
On Tue, Aug 16, 2005 at 06:13:38PM -0700, Justin Erenkrantz wrote:
> On Mon, Aug 15, 2005 at 09:55:34AM +0100, Colm MacCarthaigh wrote:
> > mod_cache configurability sucks big-time. CacheEnable adds yet another
> > location mapping scheme for administrators to deal with, but this scheme
> > lacks basic flexibility;
> > 
> > 	It can't reliably disable caching for a directory. 
> 
> As I mentioned in my previous email, we know nothing about directories at the
> time that the cache is run. 

We know everything about directories when entities are cached, and we
know what entities have been cached when the cache is run :-) 

It's not even a big patch, it's just a bad idea ;-) But don't get
trapped into thinking that this isn't technically easy either with the
existing handler system.

> > 	It's about 99.9% useless for a forward proxy configuration. ;-)
> 
> I'm not sure why you think that.  Can you expand upon this?

See my patch making CacheEnable useful for a forward proxy :)

> > 	2. If an admin re-configures with caching enabled for less
> > 	   locations that they had previously, they have to know to 
> > 	   either clear the cache or to know that the entities will 
> > 	   still get served from the cache until they have expired. 
> > 	   The patch includes a new Caching user guide, for this and 
> > 	   other reasons.
> 
> 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. 

> > 	# 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 :)

> I do think this is likely a more intuitive way to configure it if we can do it
> without impacting overall performance.

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.

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.

> > But I'm still not finished, and I'd like some advice on what next. The
> > per-dir information isn't availabe at the quick-handle stage, so the
> > mod_cache handle has to rely on per-server config to decide which
> > providers to try and use for serving content. (right now I've simply
> > hard-coded mem and disk).
> 
> Why must they be hard coded?

They must not :-) I simply sensed that my diff's were rapidly becoming
way out of the bounds of what others more knowledgeable than I would
consider rational and decided to ask for comments for proceeding. Many
thanks to all who did :)

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message