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