[....snip....] >> >> <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
IMO, this is why we should revive my original work[1] to enable mod_cache to run as both a Quick Handler and a Normal Handler. We could also invent a new handler, 'middle' handler, that runs after map_to_storage, but before the rest of the hooks. (And hence, ran once we have done directory blocks) -Paul [1] http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111597814015667&w=2
