perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Iosif Fettich <>
Subject Re: who's putting that <pre> tag in the output...?
Date Tue, 24 Mar 2009 12:02:19 GMT
Hi Torsten,

> An ErrorDocument is an internal redirect. These REDIRECT_... environment 
> variables are copied from the previous ($r->prev) request's 
> $r->subprocess_env just by copying everything and prepending REDIRECT_ 
> to each key. So if the original request has an environment variable 
> named REQUEST_URI the error document should have a REDIRECT_REQUEST_URI, 
> see rename_original_env() in httpd-x.y/modules/http/http_request.c.
> Since REQUEST_URI is the standard CGI environment variable (see
> ap_add_cgi_vars() httpd-x.y/server/util_script.c) I'd take

As it turned out, I was (entirely) wrong when I thought it is 
working. It was wishfull thinking - but not a real solution - neighter one 
variables seemed to be good enough for a mod_rewrite solution, or at least 
I was unable to build one. (I just made some errors in testing and 
repeatedly out- and out-out-commenting various httpd.conf setting, but it 
wasn't _really_ working whein I thought it would).

Summing up what I have so far ( which might be incomplete or even wrong):

looking for a cheap/good/working solution for a way to solve what

describes under the title "Redirect Failing URLs to Another Web Server", 
but with the (it seems important) difference that I want to hide the new 
server from the eyes of the customers and as such _proxy_ the failing 
requests instead of redirecting, the given receipt

RewriteEngine on
RewriteCond   %{REQUEST_URI} !-U
RewriteRule   ^(.+)          http://webserverB.dom/$1

shows up to NOT work when I attempted to make it

RewriteEngine on
RewriteCond   %{REQUEST_URI} !-U
RewriteRule   ^(.+)          http://webserverB.dom/$1 [P]

Neither was I able to use the Error_Document trick you sugegsted and use 
Rewrite on/with it.

I've given up my first attempt - the earlier in the thread shown 
PerlResponse handler - as I was unable to output the Content-Type header 
as 'text/html'; I haven't however tried the solution suggested with adding 
an extra filter for the end phase to substitute the 'text/plain' that I 
was seeing and which actually generated the initial question for this 
thread and it's subject.

I finally went the 'standard way' [?]  and added

ErrorDocument 404  /cgi-bin/

in httpd.conf, making /cgi-bin/ to be


use LWP::UserAgent;

my $ua = LWP::UserAgent->new;

my $url = $ENV{'REQUEST_URI'};
    $url = "http://OLD.SERVER.COM/$url" ;

my $response = $ua->get( $url );

my $body = $response->content;

my $h = $response->{'_headers'};
    $h->push_header( 'Status' => $response->code );
my $header = $h->as_string;

print $header;
print "\n";
print $body;


This way might have it's own special problems too, but at least it seems 
to work OK so far and give me a start.

I'm still [a bit] convinced that a mod_perl solution might or should be 
available and be both better and more effective, but I wasn't able to get 
it working - even after spending much more effort than I thought initially 
that it will take - and gave up for now.

Many thanks to all those that offered advice or help.

Iosif Fettich

PS. Firebug once again proved to be an invaluable resource in helping 
understand what's up and find a solution.

View raw message