www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: mod_proxy patches for HTTP Header manipulation
Date Sat, 12 May 2001 01:06:45 GMT
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:kwindla@allafrica.com]
> Sent: Fri, May 11, 2001 4:57 PM
> To: modproxy-dev@apache.org
> 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
> 

Mime
View raw message