Graham Leggett writes: ... > > The basic problem is that by adding the code to the proxy, only the > proxy can use the code. This is one of the main reasons we ripped the > cache code out of mod_proxy in v2.0 - it should be possible for the > whole of Apache to use a cache, not just proxy. > ... > > In theory mod_headers in v2.0 should be a filter, not a fixup. This way > potential ordering problems are solved, and the ability will exist to > filter both incoming and outgoing headers from any piece of Apache > (including mod_cgi, mod_proxy, etc). >
Absolutely. I'll write to Paul Sutton, whose name is on mod_headers, and see if I can contribute to a v2.0 mod_headers rewrite. ... > > This is because when a cached file expires, the new revalidated cached > file won't be available to the rest of Apache until it has downloaded > completely. This means there is a short window where all requests will > go through to the backend server, until at least one download is > complete, and that cached download suddenly becomes available to other > processes. > That's right. In fact, the first bit of hacking I did on the mod_proxy code was a simple "mark as being fetched" plus "just wait around for a bit if you find a stale-but-marked file" pair of patches to proxy_cache.c But I decided to abandon that approach for a few reasons, the two most important being: First, in the context of the 1.3.x development cycle, this seemed like a pretty big change in how the cache works. I thought it would be more likely that people would be receptive of a patch that doesn't do anything except operate on headers. Second, though changing the cache to prevent lots of requests during the re-generate window did solve our traffic pile-up problem, it didn't address our need to decouple internal and external caching behavior for logging/etc reasons. > The v2.0 cache is being designed so this either won't happen or a > workaround will be available. > Cool! Thanks, Kwin
