Hi,
I know this is not quite what you're looking for, but you might find
it useful for what you're doing...
We have a somewhat similar setup, and needed to be able to set
arbritrary headers on my front-end servers so that the application
servers could figure out what they should be doing with any given
request. We patched (to 1.3.19) to add four new configuration
directives that together allow finer control over header
setting/unsetting/modifying:
CacheFreshenDate
ProxyResponseExpiresVector
ProxyRequestHeader
ProxyResponseHeader
We've been running this code in production (roughly 300,000 page views
per day) for several months, now. The documentation and patch file are
available from:
http://allafrica.com/tools/apache/mod_proxy/
The "ProxyRequestHeader" directive is probably the most useful of the
group, here is its documentation (from
http://allafrica.com/tools/apache/mod_proxy/mod_proxy.html#proxyrequestheader):
----
ProxyRequestHeader directive
Syntax:
ProxyRequestHeader set | unset | add | append header [string] [match-pattern]
Default: Off
Context: server config, virtual host
Override: Not applicable
Status: Experimental
Module: mod_proxy
Compatibility:
Patch, available from http://allafrica.com/tools/apache/mod_proxy/
The ProxyRequestHeader sets headers on upstream requests. The first
argument, one of set | unset | add | append, indicates the action to
be taken for the second argument, the header. (The trailing colon
should not be included in the header argument.) The third argument is
the string that should be used for a set, add or append action (for an
unset, the string argument should be ommitted.) The optional fourth
argument, match-pattern, controls the application of the directive. If
a match-pattern is present, the request uri must match the pattern for
the directive to be applied.
ProxyRequestHeader directives can appear in server and virtual server
configuration sections. For each request, the directives are processed
in declaration order -- base server directives processed first. For
each match found, the specified action is taken.
ProxyRequestHeader set Language "unknown"
ProxyRequestHeader append Passed-Through this.host
<VirtualHost english.stuff.org>
ProxyRequestHeader set Language "en"
ProxyRequestHeader set Root-Request "yes" "^/$"
<VirtualHost english.stuff.org>
----
Kwin
=?iso-8859-1?Q?Morten_Bj=F8rhus?= writes:
> Your case is definitely not unique --- we would also be very interested
> in such a patch since we are running Apache 3.20 in a production
> environment as a reverse proxy with several virtual hosts, all having
> some ProxyPass directives to the same web application (which selects a
> branding based on the virtual host name used, essentially). And we have
> of course experienced the same problem of figuring out how to get the
> proxied webapp to recognize which virtual host name is currently used.
> Your patch is just what we would need to get a clean and simple solution
> to this.
>
