Re: Weird mod_perl CGI.pm interaction (Bug?)
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), e, 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. -- Jason Czerak On Fri, 8 Feb 2002 17:02:20 + (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 CBEGIN 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, CBEGIN blocks in that code will only be run once. As the Cperlmod manpage explains, once a CBEGIN block has run, it is immediately undefined. In the mod_perl environment, this means that CBEGIN 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. Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
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), e, 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. - Perrin
Re: Weird mod_perl CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 17:02:20 + (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 CBEGIN 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, CBEGIN blocks in that code will only be run once. As the Cperlmod manpage explains, once a CBEGIN block has run, it is immediately undefined. In the mod_perl environment, this means that CBEGIN 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. Michael
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. -- Tim Tompkins Mike McLagan wrote: On Fri, 8 Feb 2002 17:02:20 + (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 CBEGIN 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, CBEGIN blocks in that code will only be run once. As the Cperlmod manpage explains, once a CBEGIN block has run, it is immediately undefined. In the mod_perl environment, this means that CBEGIN 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. Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
try print B::show(), \n;
END
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.com/Work/resume.html
On Thu, 7 Feb 2002, Mike McLagan wrote:
Hello,
I have two scripts, call them A and B. Here's what I'm doing (paraphrased
heavily to save posting a huge pile of code):
In data.html, I have:
!--#include virtual=A?action=show --
In A, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
sub show
{
Apache::Include-virtual(B?action=remove);
}
In B, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
remove() if $q-param('action') eq 'remove';
sub show
{
print B::show()\n;
}
sub remove
{
print B::remove()\n;
}
Inveriably, I end up with B::show() in my output, not at all what I wanted,
expected or hoped for.
What I see happening is that Apache::Registry is loading CGI.pm into the httpd
child the first time it encounters a script that uses it. This runs a number
of functions within CGI.pm which set up variables, etc. The call to new() in A
then reads the query (GET or POST, doesn't matter) into @QUERY_PARAM.
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.
I'm not sure who to pin this on, mod_perl, Apache::Registry or CGI but it would
seem to me that this qualifies as a bug, somewhere.
Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 02:42:31 + (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. Michael
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 CBEGIN 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, CBEGIN blocks in that code will only be run once. As the Cperlmod manpage explains, once a CBEGIN block has run, it is immediately undefined. In the mod_perl environment, this means that CBEGIN 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. 73, Ged.
Re: Weird mod_perl CGI.pm interaction (Bug?)
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?
Regards,
Tim Tompkins
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
- Original Message -
From: Mike McLagan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 07, 2002 10:59 AM
Subject: Weird mod_perl CGI.pm interaction (Bug?)
Hello,
I have two scripts, call them A and B. Here's what I'm doing
(paraphrased
heavily to save posting a huge pile of code):
In data.html, I have:
!--#include virtual=A?action=show --
In A, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
sub show
{
Apache::Include-virtual(B?action=remove);
}
In B, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
remove() if $q-param('action') eq 'remove';
sub show
{
print B::show()\n;
}
sub remove
{
print B::remove()\n;
}
Inveriably, I end up with B::show() in my output, not at all what I
wanted,
expected or hoped for.
What I see happening is that Apache::Registry is loading CGI.pm into the
httpd
child the first time it encounters a script that uses it. This runs a
number
of functions within CGI.pm which set up variables, etc. The call to new()
in A
then reads the query (GET or POST, doesn't matter) into @QUERY_PARAM.
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.
I'm not sure who to pin this on, mod_perl, Apache::Registry or CGI but it
would
seem to me that this qualifies as a bug, somewhere.
Michael
Weird mod_perl CGI.pm interaction (Bug?)
Hello,
I have two scripts, call them A and B. Here's what I'm doing (paraphrased
heavily to save posting a huge pile of code):
In data.html, I have:
!--#include virtual=A?action=show --
In A, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
sub show
{
Apache::Include-virtual(B?action=remove);
}
In B, I have:
$q = new CGI;
show() if $q-param('action') eq 'show';
remove() if $q-param('action') eq 'remove';
sub show
{
print B::show()\n;
}
sub remove
{
print B::remove()\n;
}
Inveriably, I end up with B::show() in my output, not at all what I wanted,
expected or hoped for.
What I see happening is that Apache::Registry is loading CGI.pm into the httpd
child the first time it encounters a script that uses it. This runs a number
of functions within CGI.pm which set up variables, etc. The call to new() in A
then reads the query (GET or POST, doesn't matter) into @QUERY_PARAM.
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.
I'm not sure who to pin this on, mod_perl, Apache::Registry or CGI but it would
seem to me that this qualifies as a bug, somewhere.
Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
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.
Re: Weird mod_perl CGI.pm interaction (Bug?)
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. -- Jason Czerak
Re: Weird mod_perl CGI.pm interaction (Bug?)
On Thu, 7 Feb 2002 18:38:53 + (GMT), 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 I dug thru the guide and I found no mention at all of anything similar to this. If you happen to know where it is, please point it out because I was not at all successful. Guide or not, it still represents undesirable behavior. Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
Hi there, 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 73, Ged.
Re: Weird mod_perl CGI.pm interaction (Bug?)
On Fri, 8 Feb 2002 01:18:19 + (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? Michael
Re: Weird mod_perl CGI.pm interaction (Bug?)
Hi again, On Thu, 7 Feb 2002, Mike McLagan wrote: On Fri, 8 Feb 2002 01:18:19 + (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 Could you give me the specific jump tag for the section you are refering to please? =head3 Reloading Configuration Files When the require(), use() and do() operators successfully return, the file that was passed as an argument is inserted into C%INC (the key is the name of the file and the value the path to it). Specifically, when Perl sees require() or use() in the code, it first tests C%INC to see whether the file is already there and thus loaded. If the test returns true, Perl saves the overhead of code re-reading and re-compiling; however calling do() will (re)load regardless. You generally don't notice with plain perl scripts, but in mod_perl it's used all the time; after the first request served by a process all the files loaded by require() stay in memory. If the file is preloaded at server startup, even the first request doesn't have the loading overhead. We use do() to reload the code in this file and not require() because while do() behaves almost identically to require(), it reloads the file unconditionally. If do() cannot read the file, it returns Cundef and sets C$! to report the error. If do() can read the file but cannot compile it, it returns Cundef and sets an error message in C$@. If the file is successfully compiled, do() returns the value of the last expression evaluated. 73, Ged.
