On Sat 15 Aug 2009, Jonathan Swartz wrote:
> We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},
> $ENV{SERVER_PORT}, $r->server->port and the like to generate external
> redirects.
>
> This has worked fine til now, but now we are moving to a system where
> our external port != our internal port - the load balancer is going
> to forward ports 80 and ports 443 to non-secure ports 8080 and 8443
> (so that we can run httpd as a non-root user.) Unfortunately, the
> code mentioned above will then use the wrong (internal) ports in the
> redirects. If I were using Apache reverse proxy, ProxyPassReverse
> would take care of this, but I'm not.
>
> The legacy code is scattered in many files and will be difficult to
> change. Thus I'm wondering if there's an easy way to get %ENV and $r
> to reflect the external ports, without going through and changing
> each port-related $ENV and $r value by hand.
>
> e.g. In the Apache code I see that the ENV vars are populated via
> ap_get_server_port - is there a way for me to hook in early enough
> that I can change this?
According to the docs the server port can also be set. But I think this is not
a good idea.
The $r->server->port part can possibly be circumvented by reassigning a new
function to the Apache2::ServerRec::port symbol at startup time. Try this in
your startup.pl:
use Apache2::ServerRec ();
BEGIN {
my $old=\&Apache2::ServerRec::port;
*Apache2::ServerRec::port=sub {
if( @_==1 ) { # read access
my $port=$old->(@_);
if( $port==8080 ) {
return 80;
} elsif(...) {
...
} else {
return $port;
}
} else {
return $old->(@_);
}
};
}
As for the %ENV part this approach may work. Call $r->subprocess_env in void
context without parameters somewhere before the response phase, e.g. fixup.
This initializes the CGI variables in %ENV or rather $r->subprocess_env. Then
use $r->subprocess_env to change what you need. The subsequent perl-script
handler will know that the CGI variables are already set up and won't do it
again. So your script should see the overridden values. That's the theory.
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
