modperl_a_cgi_pm_gotcha

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.

===

the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu