I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp
Say I have a mod_perl script called x.cgi configured for mod_perl as
follows:
<Location /cgi/x.cgi>
SetHandler perl-script
PerlHandler ModPerl::PerlRun
Options ExecCGI
PerlSendHeader On
</Location>
**NOTE that I am using ModPerl::PerlRun
x.cgi uses CGI.pm as follows:
----
use strict;
use CGI qw (:cgi);
my $inp = param('inp');
print STDERR ("inp = $inp\n");
----
x.cgi works fine as a ModPerl::PerlRun script except for the case where
I use it multiple times as a Server Side Include in the same .html file
as follows:
<HTML><HEAD></HEAD>
<BODY>
<!--#include virtual="/cgi/x.cgi?inp=50"-->
<P>
<!--#include virtual="/cgi/x.cgi?inp=51"-->
</BODY>
</HTML>
In such a case the value of inp prints as 50 for both calls.
I've tested this on a single httpd process system and x.cgi works
properly for multiple calls to it (with different values for inp) during
the life of that single httpd process. I only get the strange incorrect
results when used as a server side include multiple times within the
same html file.
After attempting to track down the problem, the best I can come up with
is there is a global @QUERY_PARAM array in CGI.pm that does not get
cleared when x.cgi is uses multiple times as server side include in the
same html file. If @QUERY_PARAM is not cleared, CGI.pm continues to use
the same QUERY_STRING.
However, I don't believe this is a CGI.pm bug. I believe
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is used
mutliple times as a server side include in the same html file.
I'm guessing there is either a problem with ModPerl::PerlRun or Apache
2.0.54.
Perhaps there is some httpd.conf or perl.conf configuration I should be
looking at?
Thanks for any help you can provide as currently the only solution I
have is to hack up CGI.pm but I don't believe that is the best solution
as the relevant code of CGI.pm does not appear to have changed from
another version of CGI.pm on a different system where this works fine.
--
Jim Albert
