Re: Problems with proxying POST?
Chris Lewis wrote: [Given that Stronghold is a bit old, I'm endeavering to build Apache/mod_ssl/mod_perl from scratch, but it complains about not being able to load Apache.pm... Is there a step-by-step set of Solaris instructions somewhere?] Maybe following helps: 03ae01c0229b$a33af840$0e4077cc@tabula">http://forum.swarthmore.edu/epigone/modperl/gendkilblul/03ae01c0229b$a33af840$0e4077cc@tabula
Re: Problems with proxying POST?
On Thu, 28 Sep 2000, Chris Lewis wrote: It works to proxy the HTTP to the system fine, however, POST parameters seem to get mangled and/or truncated. they should get passed through by mod_proxy, provided nobody else has read the POST data first. When I try to reference $r-content the thing appears to hang. that means something else has already read the POST data. btw, in the cvs version, multiple calls to $r-content will not block, but anything after the first call returns undef.
Re: Problems with proxying POST?
Doug MacEachern wrote: On Thu, 28 Sep 2000, Chris Lewis wrote: It works to proxy the HTTP to the system fine, however, POST parameters seem to get mangled and/or truncated. they should get passed through by mod_proxy, provided nobody else has read the POST data first. When I try to reference $r-content the thing appears to hang. that means something else has already read the POST data. btw, in the cvs version, multiple calls to $r-content will not block, but anything after the first call returns undef. What I actually seem to be seeing is that one of the parameters has the last two characters lopped off its value. Is there something other than $r-content or $r-read that could eat the POST data? as_string? [Given that Stronghold is a bit old, I'm endeavering to build Apache/mod_ssl/mod_perl from scratch, but it complains about not being able to load Apache.pm... Is there a step-by-step set of Solaris instructions somewhere?]
Re: Problems with proxying POST?
I figured out what it was. One of the $r-header_in() was trying to insert an Authorize header, and I didn't notice that base64_encode() tacks on a newline. After Apache core got thru with it, it ended up looking like: Authorize: Basic \n \r\n \r\n parameters which caused the destination server to start parsing the parameters two characters early, hence the last parameter had two characters lopped off the end. Sigh. Thanks all.
Problems with proxying POST?
I'm writing a perl trans handler to invoke mod_proxy for non-proxy
requests.
Stronghold 3 on Solaris 2.6, server announces:
Stronghold/3.0 Apache/1.3.12 C2NetEU/3011 (Unix) PHP/3.0.16
mod_ssl/2.6.4 OpenSSL/0.9.5a mod_perl/1.22
I'm essentially using the code from page 371 of the Eagle book without
the URL translate::
my $host = $r-get_server_name;
add some headers etc. using $r-header_in
my $newuri = Apache::URI-parse($r);
my $scheme = $newuri-scheme;
my $newuristring = "$scheme://$host" . $r-uri;
if ($newuristring) {
$r-proxyreq(1);
$r-uri($newuristring);
$r-filename("proxy:$newuristring");
$r-handler('proxy-server');
return OK;
}
It works to proxy the HTTP to the system fine, however, POST parameters
seem to get mangled and/or truncated.
I'm not actually even changing the URI, because the server's notion of
name resolution is different than the browser's.
In short: external DNS maps all of the sites this thing will proxy to do
the server itself. The server has a /etc/hosts file that remaps all of
the host names to the real servers. Hence, I don't actually have to
change the uris.
Shouldn't POST parameters go thru without playing around with
read/content?
When I try to reference $r-content the thing appears to hang.
