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: [EMAIL PROTECTED]
