This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) From: Jason Czerak <Jason-Czerak@Jasnik.net> To: Ged Haywood <ged@www2.jubileegroup.co.uk> Cc: Mike McLagan <mmclagan@invlogic.com>, Date: 07 Feb 2002 13:42:52 -0500 On Thu, 2002-02-07 at 13:38, Ged Haywood wrote: > Hi there, > > On Thu, 7 Feb 2002, Mike McLagan wrote: > > > I have two scripts, call them A and B. > [snip] > > $q = new CGI; > [snip] > > Inveriably, I end up with "B::show()" in my output, not at all what I wanted, > > Isn't this mentioned in the mod_perl Guide? > > http://perl.apache.org/guide > > 73, > Ged. > > As I mentioned ealier today. I asked the question. 'do you have threaded support compiled into perl?'. If you do, this was the solution I needed to fix the same problem that I have been having also. === From: "Mike McLagan" <mmclagan@invlogic.com> To: "Ged Haywood" <ged@www2.jubileegroup.co.uk> Cc: "modperl@apache.org" <modperl@apache.org> Date: Thu, 07 Feb 2002 20:35:58 -0500 (EST) Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) On Fri, 8 Feb 2002 01:18:19 +0000 (GMT), Ged Haywood wrote: >On Thu, 7 Feb 2002, Mike McLagan wrote: > >> >Isn't this mentioned in the mod_perl Guide? >> > >> >http://perl.apache.org/guide >> > >> >> I dug thru the guide and I found no mention at all of anything >> similar to this. > >http://perl.apache.org/guide/porting.html Ged, I looked thru most of those and I can't see which of the large collection of items you believe describes the situation I brought up. Could you give me the specific jump tag for the section you are refering to please? === From: "Mike McLagan" <mmclagan@invlogic.com> To: "Ged Haywood" <ged@www2.jubileegroup.co.uk> Cc: "modperl@apache.org" <modperl@apache.org> Date: Fri, 08 Feb 2002 10:27:55 -0500 (EST) Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) On Fri, 8 Feb 2002 02:42:31 +0000 (GMT), Ged Haywood wrote: >Hi again >> Could you give me the specific jump tag for the section you are refering to please? > > >=head3 Reloading Configuration Files Ged, I read this over. It does not directly address the issue that I brought up in my original email. This discussed the loading and compilation of code. I recognise and acknowledge that one of the main points of mod_perl is that the code does not need to be recompiled from invocation to invocation. This, however, is not the point of my message. My message is about data space. The data space for the modules does not seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one invocation of a script to another. This has some rather serious, if not downright disturbing consequences. The equating of my bug report with module loading and query retrieval implies a number of things. Specifically, based on the above referenced guide text, module CGI.pm is not reloaded by the server from invocation to invocation. A good thing, for the most part. The problem comes when a child server does not die between client services on a busy server. Unless mod_perl is specifically working around it, this implies that the global data space for CGI.pm is not cleared and therefore is available to the next caller. IE, client1 comes and executes /cgi-bin/login with a particular set of POST parameters (his name/password). If the child which serviced client1 does not exit and client2 comes along and tries to execute /cgi-bin/login within the same child, he would presumably get logged in with the name/pwd that were supplied by client1. VERY BAD. If this is not the case, mod_perl has a work-around built into it that clears out the data space of precompiled modules for each external request. If that work around is coded into mod_perl, I am saying that there is a bug in that it (if such a work around does exist) is not being executed by sub-requests made from the initial request. There is no reason that the same data space clearing should not take place for a sub-request as would be done for an outside request. If I had the familiarity with the code and the time, I would dig into the source some and see what I could find in terms of code which is related to this issue but I really don't have either right now. I would strongly suggest that someone who is familiar with the code involved in this part of mod_perl, Apache.pm and CGI.pm take a hard look at this because, IMHO, it has some serious implications. === Date: Fri, 8 Feb 2002 17:02:20 +0000 (GMT) From: Ged Haywood <ged@www2.jubileegroup.co.uk> To: Mike McLagan <mmclagan@invlogic.com> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Hi Mike, On Fri, 8 Feb 2002, Mike McLagan wrote: > My message is about data space. The data space for the modules does not > seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one > invocation of a script to another. Yes, this is well known to mod_perl users and it's in the Guide, in the same chapter that I've already suggested that you read: =head1 BEGIN blocks Perl executes C<BEGIN> blocks as soon as possible, at the time of compiling the code. The same is true under mod_perl. However, since mod_perl normally only compiles scripts and modules once, either in the parent server or once per-child, C<BEGIN> blocks in that code will only be run once. As the C<perlmod> manpage explains, once a C<BEGIN> block has run, it is immediately undefined. In the mod_perl environment, this means that C<BEGIN> blocks will not be run during the response to an incoming request unless that request happens to be the one that causes the compilation of the code. If you are having trouble coping with mod_perl and CGI.pm perhaps it would better if you tried different approach, Apache::Request for example has some useful features. === From: "Tim Tompkins" <timt@arttoday.com> To: "Mike McLagan" <mmclagan@invlogic.com>, <modperl@apache.org> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Date: Fri, 8 Feb 2002 10:29:16 -0700 This is aparently the nature of Apache::Include. It executes the given script within the current request while ignoring any query string that you may provide. So, including B from A makes all parameters supplied to A available to B, and supplying a query string to B does nothing. Moreover, calling new CGI from B will do just that. It will have the params supplied in the initial request. So, if you modify $q in script A before including B, B will not be aware of those changes made in A. Are we all completely confused now? === From: "Mike McLagan" <mmclagan@invlogic.com> To: "Ged Haywood" <ged@www2.jubileegroup.co.uk> Cc: "modperl@apache.org" <modperl@apache.org> Date: Sat, 09 Feb 2002 09:50:23 -0500 (EST) Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) On Fri, 8 Feb 2002 17:02:20 +0000 (GMT), Ged Haywood wrote: >> My message is about data space. The data space for the modules does not >> seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one >> invocation of a script to another. > >Yes, this is well known to mod_perl users and it's in the Guide, in >the same chapter that I've already suggested that you read: > >=head1 BEGIN blocks > >Perl executes C<BEGIN> blocks as soon as possible, at the time of >compiling the code. The same is true under mod_perl. However, since >mod_perl normally only compiles scripts and modules once, either in >the parent server or once per-child, C<BEGIN> blocks in that code will >only be run once. As the C<perlmod> manpage explains, once a C<BEGIN> >block has run, it is immediately undefined. In the mod_perl >environment, this means that C<BEGIN> blocks will not be run during >the response to an incoming request unless that request happens to be >the one that causes the compilation of the code. Broken behavior, defined or not, is still broken behavior. Maybe it's up to the CGI.pm author to investigate what he has to do to work around this problem, but that's still a work around for broken behavior. >If you are having trouble coping with mod_perl and CGI.pm perhaps it >would better if you tried different approach, Apache::Request for >example has some useful features. Linux Online has been using mod_perl and CGI.pm for over 4 years now, I'm not about to change because I've tripped over this bug. As my original message said, I found a solution, albeit an unreasonable one. If Apache::Request was perl only, I might look into it since we only use CGI.pm for it's query parsing abilities but with the need to drag along a C library, I'll pass. === Date: Sat, 09 Feb 2002 14:12:02 -0700 From: Tim Tompkins <timt@arttoday.com> To: Mike McLagan <mmclagan@invlogic.com> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Saying that BEGIN blocks should be re-run on every invocation of the script in mod_perl is like saying that you must re-start your car every time you stop even though the engine may still be running. The fact that BEGIN blocks only execute once per server instance is expected simply by definition of the BEGIN block. If you wrote a daemon in perl that stood waiting for connection, would you expect the BEGIN block to execute every time it responded to a request? I certainly wouldn't. I would only expect it to run only when I fired it up. This certainly does not qualify as being "broken." It is the way BEGIN blocks work -- they are executed at compile time as soon as they are completely defined and quite possibly even before other code is parsed from that script. If I were to say the following: ($hour,$min,$sec) = (localtime)[0,1,2]; When the documentation clearly states that the first three elements from localtime are seconds, mintutes then hours. Which would be broken, localtime() or my code? The fact is that I must code according to the way it is documented, not the way I think it should be. Please note that what you're experiencing in your initial post is not even related to BEGIN block execution. Please see my previous post in this thread for the explanation for your problem regarding Apache::Include. === Date: Sat, 09 Feb 2002 17:39:57 -0800 From: Perrin Harkins <perrin@elem.com> To: Mike McLagan <mmclagan@invlogic.com> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Mike McLagan wrote: > When B is invoked, within the same child, Apache::Registry DOES NOT reload > CGI.pm and therefore does not initialize any of the variables, etc. This > results in the new() call in B REUSING (!) the @QUERY_PARAM which was built up > during the new() call in A! OOOPS! > > In order to make it work, I had to dig thru CGI.pm and found a function that's > in there with comments about mod_perl around it, specifically: > > CGI::initialize_globals(); > > If I add this call in before both of the new() invocations, I get the desired, > expected results. CGI.pm does not need the BEGIN block to be called each time. It calls the initialize_globals() function from a cleanup handler when running under mod_perl. It doesn't expect you to actually modify the request before the cleanup handler runs (since the cleanup handler runs at the end of every request). You can call the function it yourself, which might mess up the original settings because of the use globals, or you can use a CGI library that doesn't rely on globals in this way. CGI::Lite looks safe based on it's OO interface, and Apache::Request is known to be safe, and there's always $r->args. === Date: Sun, 10 Feb 2002 01:35:05 +0000 (GMT) From: "Philip M. Gollucci" <philip@sduwebship.student.umd.edu> To: Mike McLagan <mmclagan@invlogic.com> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) try print B::show(), "\n"; === Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) From: Jason Czerak <Jason-Czerak@Jasnik.net> To: Mike McLagan <mmclagan@invlogic.com> Cc: Ged Haywood <ged@www2.jubileegroup.co.uk>, Date: 11 Feb 2002 00:14:03 -0500 On Sat, 2002-02-09 at 09:50, Mike McLagan wrote: I asked this question before. I had the same problem on _one_ of my machines but not any of the others. Is this perl 5.6.1 (or 5.6.0 even I dunno). And.... Do these perl installs have threading enabled? are they self compiled. if you said YES to all of those or even some (most importantly the threading bit). Recompile without threading. and then try. Keep in mind I tried several version of CGI.pm. Where the problem is (and yes, I did hack CGI.pm and fixed it but felt it was unnessary to hack CGI.pm since it wasn't at fault and didn't want to break other working apps), errrr, the problem is in the read_from_client() call where CGI.pm issues a read() from the STDIN file handle. The problem is when it's called for the second time the handle reference is missing. That is the jist of the details. I can get 100% informative if anyone wishes to know. === From: "Perrin Harkins" <perrin@elem.com> To: "Jason Czerak" <Jason-Czerak@Jasnik.net>, Cc: <modperl@apache.org> Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) Date: Mon, 11 Feb 2002 00:54:34 -0500 > Keep in mind I tried several version of CGI.pm. Where the problem is > (and yes, I did hack CGI.pm and fixed it but felt it was unnessary to > hack CGI.pm since it wasn't at fault and didn't want to break other > working apps), errrr, the problem is in the read_from_client() call > where CGI.pm issues a read() from the STDIN file handle. The problem is > when it's called for the second time the handle reference is missing. I don't think this is the same problem. Mike is actually modifying the request (by making a subrequest) before CGI.pm clears its globals (in a cleanup handler) and wanting CGI.pm to notice. It isn't that he's getting nothing from CGI.pm; it's that he's getting the same thing both times. At least that's how I interpreted it. === To: modperl@apache.org Subject: Re: Weird mod_perl & CGI.pm interaction (Bug?) From: Joe Schaefer <joe+apache@sunstarsys.com> Date: 11 Feb 2002 17:00:47 -0500 Perrin Harkins <perrin@elem.com> writes: > CGI.pm does not need the BEGIN block to be called each time. It calls > the initialize_globals() function from a cleanup handler when running > under mod_perl. It doesn't expect you to actually modify the request > before the cleanup handler runs (since the cleanup handler runs at the > end of every request). Or rather, CGI.pm expects that you *want* the original request data when you write "$q=new CGI" multiple times throughout the lifetime of the original request. The problem, as I see it, is that CGI.pm makes no direct provisions for dealing with subrequests, and IMO that is a flaw in (the mod_perl support within) CGI.pm. What I suggest would be some kludge in the caller's code like sub do_with_fresh_cgi (&) { local $CGI::Q; local (@CGI::PARAM, %CGI::PARAM); # localize other global params that I've missed, right here shift() -> (); } do_with_fresh_cgi { Apache::Include->virtual(...) ... }; === To: Rick Myers <rik@sumthin.nu> Cc: modperl@apache.org Subject: Re: CGI.pm problem From: barancev@kazbek.ispras.ru (Alexei V. Barantsev) Date: 30 Aug 2000 10:23:38 +0400 Rick Myers <rik@sumthin.nu> writes: > On Aug 29, 2000 at 16:11:39 +0400, Alexei V. Barantsev twiddled the keys to say: > > Dear mod_perl'ers! > > > > I have found strange difference between object and func modes of CGI > > library. More precisely - I have a problem with Vars function. > > > > #use CGI qw(:standard :cgi-lib); > > CGI::_reset_globals; > > > #my $args = Vars; > > _reset_globals() is normally called when you create a new CGI object. > In this context though, your object lives on between script runs so you > have to manually tell CGI to reset it. O-o-ps! Isn't it a good idea to put this tip into documentation - mod_perl traps with functional mode of CGI.pm? === Date: Wed, 16 Jan 2002 21:15:59 -0700 From: Dave Morgan <dvmrgn@telusplanet.net> To: "modperl@apache.org" <modperl@apache.org> Subject: Summary: CGI.pm problems in BEGIN blocks Hi All, Basically comes down to you cannot call the CGI.pm module in a functional style within a block of code that is loaded at startup by a mod-perl enabled web server. Using CGI.pm in an OOP way eliminates the problem. ####################################### # this code causes problems with the usage # of CGI.pm with mod-perl package NOGOOD; require Exporter; use strict; use CGI qw/:standard/; our (@ISA, @EXPORT); our ($USERID, $PASSWORD, $select_list); @ISA = qw(Exporter); @EXPORT = qw($USERID $PASSWORD $select_list); BEGIN{ $select_list = scrolling_list(-name=>'TEST', -values=>[1,2,3,4], -default=>'1', -size=> 1); } 1; # END ####################################### # this code WORKS package GOOD; require Exporter; use strict; use CGI; our (@ISA, @EXPORT); our ($USERID, $PASSWORD, $select_list); @ISA = qw(Exporter); @EXPORT = qw($USERID $PASSWORD $select_list); BEGIN{ my $cgihandler = new CGI; $select_list = $cgihandler->scrolling_list(-name=>'TEST', -values=>[1,2,3,4], -default=>'1', -size=> 1); } 1; # END I can't believe no-one else has run in to this. Something to do with the default instantiation of CGI is my guess. Thanks to all === From: "Perrin Harkins" <perrin@elem.com> To: "Dave Morgan" <dvmrgn@telusplanet.net>, <modperl@apache.org> Subject: Re: Summary: CGI.pm problems in BEGIN blocks Date: Thu, 17 Jan 2002 00:47:53 -0500 > I can't believe no-one else has run in to this. Something > to do with the default instantiation of CGI is my guess. It's actually highly unusual to do anything with CGI other than compile it inside a BEGIN block. You may very well be the first person who ever tried. Typical usage is to do initialization at the start of each request, since CGI is all about the current request context. ===