On Thu, 10 Aug 2000, Roger Espel Llima wrote:
> I'm trying to set up a proxy front-end server to my heavy mod_perl
> backend, and I'm having some trouble with name-based virtual hosts.
>
> Basically, with a rule like "RewriteRule ^/(.*) http://10.36.1.10/$1 [P]",
> the proxy sends an http request to 10.36.1.10:80, but setting the Host:
> http header to "10.36.1.10", not what the client supplied.
>
> The mod_perl guide suggests having <VirtualHost> statements on the
> front-end, and redirecting each hostname to a different port on the
> backend. This is inconvenient for me, because I'd have to change the
> app logic on the backend (which currently uses $r->header_in("Host")
> directly).
>
> Ideally, what I'd like is to have the front-end server not check or
> touch Host: at all, and pass it unaltered to the backend, which knows
> what to do with it. Does anyone know of a way to do this?
>
> If that's not possible, I'd settle for the backend getting it in a new
> header (eg. X-Original-Host), using an approach similar to
> mod_proxy_add_forward.c.
I ended up adding this to mod_proxy_add_forward.c:
ap_table_set(r->headers_in, "X-Original-Host",
ap_table_get(r->headers_in, "Host"));
(right after the line that adds the "X-Forwarded-For" header).
Then on the backend, I've got a TransHandler that essentially does an
$r->headers_in->set('Host' => $r->header_in('X-Original-Host')),
along with setting $r->connection->remote_ip to the "X-Forwarded-For"
header. I should note that it only does this if it "trusts" these
headers, in my case if the request is coming from 127.0.0.1 I trust it.
A nice plus is that the mod_perl backend server acts the same way
whether there's a proxy in front of it or not.
BTW I haven't tried this, but I would have had I not already had something
in place, since it's more flexible:
[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/lolkahcling/[EMAIL PROTECTED]