Problems with proxying POST?

[Chris Lewis <cl...@nortelnetworks.com>]

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.

Re: Problems with proxying POST?

[Chris Lewis <cl...@nortelnetworks.com>]

 
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.

Re: Problems with proxying POST?

["Alexander Farber (EED)" <ee...@eed.ericsson.se>]

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:
http://forum.swarthmore.edu/epigone/modperl/gendkilblul/03ae01c0229b$a33af840$0e4077cc@tabula

Re: Problems with proxying POST?

[Chris Lewis <cl...@nortelnetworks.com>]

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?

[Doug MacEachern <do...@covalent.net>]

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.