hi. you might want to have a look at mod_env as well as mod_header. I did a very simple hack to it, and added a SetHeaderNote which added the note to the headers_in table, which would then get forwarded into the proxy request. (this was a short term thing to get some headers passed to a app)
> -----Original Message----- > From: Kwindla Hultman Kramer [mailto:[EMAIL PROTECTED] > Sent: Fri, May 11, 2001 4:57 PM > To: [EMAIL PROTECTED] > Subject: Re: mod_proxy patches for HTTP Header manipulation > > > > 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 >
