RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...
try CGI-initialize_globals(); at the begining of the script but before you use params if you are depending on the 'use CGI' statement to initialize your params (like a command line script), it will cause problems in Registry. Thats becuase it is initialized once on the initial 'use CGI' and it stays in memory for the life of the webserver. So each time you use a script, you have to initialize the CGI params to your current request. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 12:07 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)... Steve Bannerman wrote: All, I apologize if this has already been covered...I looked at the archives since May but couldn't see anything covering this (there were related items but their solutions didn't solve this problem). Here an explanation of the problem: We want to post experiment results to an upload server which is running Apache HTTP Server (2.0.46) and mod_perl (1.99_09). When we post a sequence of files to the server, some of them are written to the local disk and some are not. That is, the test fails when using ModPerl::Registry but it succeeds when using ModPerl::PerlRun. In analyzing which ones work and which ones do not, I wrote a quick test to see why the transfer is not working. From the looks of the results, it appears that the first request handled by a particular Apache process/thread works and that any subsequent requests handled by that thread fail. Works means that the file in the test gets saved to disk and fail means that a file of size 0 gets written to disk. Below are the httpd.conf segments (working and failing), the test client (test_client.pl) and the test server (test_server.pl which is accessible from the /cpdn/cgi-bin location). Any suggestions? Thanks in advance... Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry (I have read some about this at http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the documentation there is a little light). The docs need work, this is just a copy of mp1 registry docs, which need adjustments. However most things work the same way. The differences between Registry and PerlRun are easily summarizes with this diff: ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800 +++ lib/ModPerl/PerlRun.pm 2003-03-22 20:52:24.0 -0800 @@ -1,4 +1,4 @@ -package ModPerl::Registry; +package ModPerl::PerlRun; use strict; use warnings FATAL = 'all'; @@ -30,11 +30,11 @@ make_namespace = 'make_namespace', namespace_root = 'namespace_root', namespace_from = 'namespace_from_filename', -is_cached = 'is_cached', -should_compile = 'should_compile_if_modified', -flush_namespace = 'NOP', +is_cached = 'FALSE', +should_compile = 'TRUE', +flush_namespace = 'flush_namespace_normal', cache_table = 'cache_table_common', -cache_it= 'cache_it', +cache_it= 'NOP', read_script = 'read_script', rewrite_shebang = 'rewrite_shebang', set_script_name = 'set_script_name', @@ -53,17 +53,10 @@ PerlRun doesn't cache the script on each request and it flushes the script's namespace on each request. You can see the actual functions in lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see what the problem is (your code/registry?), that would be cool. Thanks. Also make sure you are using the latest CGI.pm (2.93 or higher is good). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the installation nightmare continues
So I built, tested and made apache with: $ ./configure --prefix=/usr/local/apache $ make $ make install $ usr/locall/apache/bin/apachectl start (started fine) try letting mod_perl do the heavy lifting - mod_perl will build both itself and apache if you let it. after unzipping both apache and mod_perl sources to the same local root (say, ~jeff/src) just cd to the mod_perl directory and... edit makepl_args.mod_perl: APACHE_SRC=../apache-1.3/src APACHE_PREFIX=/usr/local/apache DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=so (add whatever modules you want here) then (as non-root user) $ perl Makefile.PL $ make $ make test and you should be good to go. in addition to the perl.apache.org install doc, this might help: http://www.modperlcookbook.org/chapters/ch01.pdf HTH --Geoff
Re: Trouble with Apache::Request
On Fri, 1 Aug 2003, Jie Gao wrote:
Hi All,
perl-5.8.0 + mp1.99_10.
---
I am having problem trying to get /perl-status work.
It bombs out in Status.pm at the following location:
--
if (eval {require Apache::Request}) {
$newQ ||= sub { Apache::Request-new(@_) };
}
elsif (eval {require CGI}) {
$newQ ||= sub { CGI-new; };
}
else {
die Need CGI.pm or Apache::Request to operate;
}
--
But shouldn't Apache::Request be Apache::RequestRec?
Apache::Request is part of the libapreq package, a port of
which to Apache2 is still being developed.
best regards,
randy kobes
Re: [mp2] Child process exited
25k zip? that's a not quite a short test case ;) Can it possibly be 25 lines of code instead? You're absolutely right, I've pared it down a lot while waiting for your answer. I was trying to get my test case to you as fast as possible, that's why I didn't spend that much time on it before. It's still not quite 25 lines, but it's much shorter. I've actually pinpointed the problem to one HTML tag in the output that Template-Toolkit sends to Apache as a result of the cgi script's run. But I still prefer giving you (or whomever will try this) the code so they can see for themselves. It's about 3k now... :-) Most likely someone on win32 will have to try it. If you can put it online somewhere and post the URL to it, that will be the best. OK, it's at http://whitestar02.webhop.org/Files/ApacheCrash.zip . Please go easy on the server, it's on a residential cable line... Inside, you'll find a simple CGI script (50 lines), one template file (26 lines) and a README (123 lines). Considering the readme file is the biggest of the bunch, and that you can determine if the server crashes or not by removing 4 tags in the template file, I think it's pretty stripped down. Please read the README before trying to run it. In it, you'll find details on my config and a short discussion of what happens in the various cases I tried. Note that since I found the tags that cause the problem, I can continue to work without them, but I'd still like to know why it crashes on a script that ran perfectly in straight CGI. Thanks a lot for trying to get this sorted. J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
the installation nightmare continues
Title: the installation nightmare continues Taking a step or two back I have started the process over again. I have created my download directory for a non-root user and built and compiled perl 5.8.0, which went smoothly and passed all of the tests along the way. This brings me to mod_perl. I opted to build apache staticly, and use the makepl_args.mod_perl file that Ged (tks ged) had suggestion. Reading through the mod-perl install site (http://perl.apache.org/docs/1.0/guide/install.html), it actually made a lot more sense after the suggestion. I'm having issues running make test for mod perl. Since Apache is staticly built, it needs to be running in order to test mod perl. snipet make test fails You cannot run make test before you build Apache, so if you told perl Makefile.PL not to build the httpd executable, there is no httpd to run the test against. Go to the Apache source tree and run make, then return to the mod_perl source tree and continue with the server testing. /snippet So I built, tested and made apache with: $ ./configure --prefix=/usr/local/apache $ make $ make install $ usr/locall/apache/bin/apachectl start (started fine) Running make test for mod perl gives: server failed to start! please examine t/logs/error_log This looks like its apache test server is not working, but apache is tested. compiled, built and started. I ran into this error before I compiled apache, and it made sense why I was getting the error, but now that this is fixed it shouldn't be a problem. I'm I missing something? also I checked modperl/t/logs/error_log where mp test should write to (and says that it is), but there is no log file
Re: Re[2]: Multiple select
On Tue, 2003-08-05 at 13:29, Alan Rafagudinov wrote: Please small example of using Apache::Request. $r-content; $r = Apache-request; does not work :-( That's not Apache::Request, that's an Apache object. Please read the documentation: http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_use_Apache_Perl_Modules http://search.cpan.org/author/JOESUF/libapreq-1.2/Request/Request.pm Or just use CGI.pm or something similar like CGI_Lite. - Perrin
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 18:29, Geoffrey Young wrote:
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase
you need to do two things - tell apache that mod_perl is in charge,
and tell mod_perl which Perl handler it should use. you've done the
latter. for the former, use $r-handler('perl-script'), which is
analogous to SetHandler perl-script that you would ordinarily see for
a mod_perl setup.
Thank you!
I tried to add that line to the Dispatcher:
package Dispatcher;
use Apache::Constants ':common';
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-handler('perl-script');
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
1;
without luck however, keeps on looking under the document root
for /admin. Should that change be enough?
-- fxn
RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...
Christopher, Thanks for the suggestion; unfortunately, it doesn't work. I made the change you suggested (inserting CGI-initialize_globals(); just before creating an instance of CGI) and restarted apache/httpd. The same result...the first time the script executes it saves the file properly...after that, a file is created with 0 size. Besides, as you (and others prescribing the use of initialize_globals()) described it, shouldn't subsequent executions of the script write the same file as the first execution. That is, if the parameters of the CGI instances are actually global, wouldn't the same array of bytes still be in the global 'file' parameter? Cheers -- Steve Bannerman [EMAIL PROTECTED] 44.(0)1865.273866 -Original Message- From: Christopher Knight [mailto:[EMAIL PROTECTED] Sent: 05 August 2003 18:20 To: Stas Bekman; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)... try CGI-initialize_globals(); at the begining of the script but before you use params if you are depending on the 'use CGI' statement to initialize your params (like a command line script), it will cause problems in Registry. Thats becuase it is initialized once on the initial 'use CGI' and it stays in memory for the life of the webserver. So each time you use a script, you have to initialize the CGI params to your current request. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 12:07 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)... Steve Bannerman wrote: All, I apologize if this has already been covered...I looked at the archives since May but couldn't see anything covering this (there were related items but their solutions didn't solve this problem). Here an explanation of the problem: We want to post experiment results to an upload server which is running Apache HTTP Server (2.0.46) and mod_perl (1.99_09). When we post a sequence of files to the server, some of them are written to the local disk and some are not. That is, the test fails when using ModPerl::Registry but it succeeds when using ModPerl::PerlRun. In analyzing which ones work and which ones do not, I wrote a quick test to see why the transfer is not working. From the looks of the results, it appears that the first request handled by a particular Apache process/thread works and that any subsequent requests handled by that thread fail. Works means that the file in the test gets saved to disk and fail means that a file of size 0 gets written to disk. Below are the httpd.conf segments (working and failing), the test client (test_client.pl) and the test server (test_server.pl which is accessible from the /cpdn/cgi-bin location). Any suggestions? Thanks in advance... Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry (I have read some about this at http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the documentation there is a little light). The docs need work, this is just a copy of mp1 registry docs, which need adjustments. However most things work the same way. The differences between Registry and PerlRun are easily summarizes with this diff: ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800 +++ lib/ModPerl/PerlRun.pm 2003-03-22 20:52:24.0 -0800 @@ -1,4 +1,4 @@ -package ModPerl::Registry; +package ModPerl::PerlRun; use strict; use warnings FATAL = 'all'; @@ -30,11 +30,11 @@ make_namespace = 'make_namespace', namespace_root = 'namespace_root', namespace_from = 'namespace_from_filename', -is_cached = 'is_cached', -should_compile = 'should_compile_if_modified', -flush_namespace = 'NOP', +is_cached = 'FALSE', +should_compile = 'TRUE', +flush_namespace = 'flush_namespace_normal', cache_table = 'cache_table_common', -cache_it= 'cache_it', +cache_it= 'NOP', read_script = 'read_script', rewrite_shebang = 'rewrite_shebang', set_script_name = 'set_script_name', @@ -53,17 +53,10 @@ PerlRun doesn't cache the script on each request and it flushes the script's namespace on each request. You can see the actual functions in lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see what the problem is (your code/registry?), that would be cool. Thanks. Also make sure you are using the latest CGI.pm (2.93 or higher is good). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---
ModPerl - CGI in the same request phase
Hi again everybody, I have the following interesting (I hope ;-) requirement. Sorry for this rather long posting. (mod_perl 1, Apache 1.3.27) I have a custom authentication authorization handler of mine which is the king in a protected directory (and its subdirectories): PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory Then, for some users that I authenticate as SuperUsers, I should allow the execution of the administrative .cgi scripts in a subdir of this dir(/usr/local/apache1/ssl/protected/admin). (One solution would be to integrate the cgi-s logic into my handler but let's say want to leave them as simple CGI scripts.) I tried to use the Apache::PerlRun in the subdir like this: PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options ExecCGI /Directory I tried also: Directory /usr/local/apache1/ssl/protected/admin SetHandler cgi-script Options +ExecCGI /Directory The problem is it allows anybody to execute the cgi's since it's not going through my handler anymore (a warn ... statement inserted in my handler shows it's not executed when requesting /protected/admin/* files.) More generally: how can I dynamically change a directory's handler during the same phase I was thinking about using dynamic stacked handlers, something like: if the user is allowed in the admin section, my handler should push the cgi-script handler in the line of execution. However, the documentation says about stacking more custom created handlers and not those coming with Apache so I'm not sure how to do it. Thanks for your time, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
RE: HTTP POST: parameters empty when using ModPerl::Registry(okay when using ModPerl:PerlRun)...
On Wed, 2003-08-06 at 04:50, Steve Bannerman wrote:
However, it doesn't really explain why the root problem exists. The way I
think about it, the creation of a new CGI object should create a new set
of slots for instance data.
That would make sense, but very little about CGI.pm actually works in
the way you would expect. It's a very bizarre module because of the
dual functional and object interface, and it uses lots of globals even
if you are only calling the OO interface. If possible, I would suggest
you consider using CGI::Simple instead, which is a drop-in replacement.
Maybe I don't understand the object paradigm in perl correctly; however, I
do understand it very well in general. Thus, it seems like a defect in
either perl (the language) or CGI.pm.
It's a problem with CGI.pm, not with your understanding of Perl OO.
I believe I see the source of your troubles in the code that you
posted. You are creating a closure by using a lexical variable and then
accessing it from within a sub. This is a no-no with any long-running
system like mod_perl. You can get away with it in a standard CGI
environment (or PerlRun) because it just exits after each request
instead of running the same code again.
Here is the offending section:
my $cgi = new CGI;
saveFile();
sub saveFile {
my $inputfile = $cgi-param('file');
... etc ...
}
Change it to this:
my $cgi = new CGI;
saveFile($cgi);
sub saveFile {
my $cgi = shift;
my $inputfile = $cgi-param('file');
... etc ...
}
I think that will do it.
- Perrin
Re: help on setting up a PerlFixupHandler
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
-- fxn
RE: help on setting up a PerlFixupHandler
Hi, It seems to me that $r-content-type is for what your server sends to the client, which is probably undef in the Fixup stage, where you test it. You probaly meant to test for the $ct = $r-header_in(Content-type) if you wanted to see whats requested from the client. Anyway, as Christopher pointed out you can get the what's before load off your shoulders ;-) HTH, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Xavier Noria [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 9:40 PM To: [EMAIL PROTECTED] Subject: Re: help on setting up a PerlFixupHandler On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
