perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Albert <>
Subject Re: ModPerl::PerlRun SSI
Date Thu, 06 Oct 2005 14:26:19 GMT
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 that is mod_perl safe. If there is 
a mod_perl safe alternative to 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.


Jim Albert wrote:

> I think I may now have a better understanding of this and that the 
> problem lies in 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::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
>> 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 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:
>> <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 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, 
>> continues to use the same QUERY_STRING.
>> However, I don't believe this is a 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 but I don't believe that is the best 
>> solution as the relevant code of does not appear to have 
>> changed from another version of on a different system where 
>> this works fine.

Jim Albert

View raw message