Lack of response on this tells me:
1. Nobody is using ModPerl::PerlRun any longer to run their scripts
under mod_perl. I doubt it.
2. There is an alternative to CGI.pm that is mod_perl safe. If there is
a mod_perl safe alternative to CGI.pm for use under ModPerl::PerlRun
scripts for things like retrieving input from QUERY_STRING and working
with cookies, please point me to what you use for this.
Thanks.
Jim Albert wrote:
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
