www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kwindla Hultman Kramer <kwin...@allafrica.com>
Subject Re: mod_proxy patches for HTTP Header manipulation
Date Fri, 11 May 2001 23:57:24 GMT

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

Mime
View raw message