I think I may now have a better understanding of this and that the
problem lies in CGI.pm. I've emailed the following to Lincoln Stein
explaining what I believe to be true. Perhaps someone can either confirm
my understanding or otherwise correct me.
My email to Lincoln Stein is as follows:
I did some more research and I believe I understand the problem and why
it only happens when the mod_perled x.cgi is used multiple times as a
server side include within the same html file.
The issue is with this line of code in CGI::new
$r->pool->cleanup_register(\&CGI::_reset_globals);
From my understanding, that sets up a apache callback to clean up your
globals **after** the apache process is done serving the request.
However, in the case where x.cgi is used multiple times as a server side
include in the same html file, _reset_globals is not called until the
apache process is done with the request.
It seems to me it would be best simply to call _reset_globals first
thing in your new() method when you detect a mod_perl environment. That
way we know all those globals are clean for each use.
Unless you can offer another suggestion, my solution at present is to
add the following to all my mod_perled scripts that use CGI.pm:
CGI::initialize_globals();
I hope you can help with this.
Jim Albert wrote:
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
