Mailing List Archive

mod_proxy drops query string
I've just completed moving from a single mod_perl executable to a httpd_docs
and httpd_perl server using mod_proxy. The problem is that sometimes when
CGIs are accessed the query string is somehow dropped, so when loading
something like /cgi-bin/script.pl?mode=dosomething, the query string would
be periodically ignored, causing wierd behaviour. Any ideas?

I'm using apache 1.3.11 with mod_perl 1.21, on redhat linux 6, and i'm using
directives like:

ProxyPass /cgi-bin/ http://www.bluesnews.com:9000/cgi-bin/
ProxyPassReverse /cgi-bin/ http://www.bluesnews.com:9000/cgi-bin/

to proxy the requests.
--
James Furness <furn@bluesnews.com>
ICQ #: 4663650
Re: mod_proxy drops query string [ In reply to ]
Yeah, I thought this was a tad weird.

I can reproduce the problem reliably by hitting reload. For example
http://www.bluesnews.com/cgi-bin/finger.pl?id=1 will run OK some of the
time, but every so often will give a "No ID specified" error, indicating
that the script did not receive the query string (Note this URL will work
perfectly at the moment since I have had to revert to a single httpd due to
the problem). As soon as I get a chance I will probably try doing some
testing with printenv to see exactly what is going on, but at the moment I
have been waiting to see if anyone on the list has any ideas or similar
experiences.
--
James Furness <furn@bluesnews.com>
ICQ #: 4663650
----- Original Message -----
From: "G.W. Haywood" <ged@jubileegroup.co.uk>
To: "James Furness" <furn@bluesnews.com>
Sent: Tuesday, February 22, 2000 4:38 PM
Subject: Re: mod_proxy drops query string


> Hi there,
>
> On Sat, 19 Feb 2000, James Furness wrote:
>
> > I've just completed moving from a single mod_perl executable to a
httpd_docs
> > and httpd_perl server using mod_proxy. The problem is that sometimes
when
> > CGIs are accessed the query string is somehow dropped, so when loading
> > something like /cgi-bin/script.pl?mode=dosomething, the query string
would
> > be periodically ignored, causing wierd behaviour. Any ideas?
>
> How are you getting on with this? I haven't seen anything on the
> List. There's not a lot to go on here, have you got any more info?
> Can you get something to reproduce the problem reliably? It's the
> obvious first step.
>
> 73,
> Ged.
>
> >
> > I'm using apache 1.3.11 with mod_perl 1.21, on redhat linux 6, and i'm
using
> > directives like:
> >
> > ProxyPass /cgi-bin/ http://www.bluesnews.com:9000/cgi-bin/
> > ProxyPassReverse /cgi-bin/ http://www.bluesnews.com:9000/cgi-bin/
> >
> > to proxy the requests.
> > --
> > James Furness <furn@bluesnews.com>
> > ICQ #: 4663650
> >
>
Re: mod_proxy drops query string [ In reply to ]
Hi again,

On Wed, 23 Feb 2000, James Furness wrote:

> Well firstly no system calls are done, it just pulls things out of
> the database.

Hmmph.

> Secondly, if i'm understanding you correctly, you're saying this
> might be an issue with the CGI script itself

I never like to be too confident about anything.

> surely the problem would have been present with a single httpd (no
> proxy) before I moved to a httpd_docs/httpd_perl configuration.

That's more a brave assertion than a proof of validity.

> Also, it just occurred to me, previously when playing with printenv,
> I was getting forwarded-for headers from the mod_proxy_add_forward
> module, but the PerlHandler I put in (Code straight from the guide)
> was not being executed at all. I put some debug code in to print to
> STDERR when it was executed and the messages never appeared. But I
> decided to ignore it as a trivial problem

If there's one thing I've learned in (int XX = large number I don't
like to think about;) years of programming, it's that if you ignore
something like that it will generally come back and bite you.

> No proxy (httpd -X would be a bit stupid seeing as we're getting
> 1,000s of hits a day :)

Well, depends on what the hits are asking for. If the light server
can serve most of the requests without the mod_perl server getting
involved, then using -X for the heavy server could be a good way to
find out if things are really as they seem. That's the other thing
I've learned in the XX years. They often aren't...

You might try a third (heavy) server to play around with, kind of like
a private version of your site, then you could test without pressure.

Anything else in the logs?

73,
Ged.