Re: CGI.pm and friends port to mp2
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept it in.
Lincoln
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require mod_perl };
?
__
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
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
Lincoln
On Thursday 13 March 2003 06:21 pm, Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate
it if people could test it on both mod_perl 1 and mod_perl 2, as well as
under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test
suites aren't exhaustively cover CGI.pm's functionality. So we really need
your help guys to give it a good test in the real apps.
In case anyone wonders why I fiddled with the check for the presence of
modperl, this is because some people write scripts that shell out to
command-line scripts that invoke CGI.pm in order to generate HTML (don't
ask me why). Without the additional checking, CGI.pm sees the MODPERL
environment variable, tries to load mod_perl outside the Apache
environment, and summarily crashes.
Ahm, I'm not quite sure that this does what you say it should:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
because if it's not defined, it'll fall through to the else block, assuming
that the external script is running under mp1. Shouldn't it be:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
if ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
}
also it's probably a good idea to add a note, why this check is done, so
not to forget in the future and optimize it away ;)
I still haven't heard any response as to why I should move to MP2! I
wasn't just being cranky, I'm curious.
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on win32, serialization)
and there is a whole bunch of new functionality available, which will be
too long to list here and partially described on the website.
__
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
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote:
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
That's not what you have sent before ;) But it looks OK in the most recent
version.
A few more comments.
- I have suggested to add a note explaining why we don't rely on
$ENV{MOD_PERL}. I'm sure the reason will be forgotten in the future.
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require mod_perl };
?
__
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: CGI.pm and friends port to mp2
Lincoln Stein wrote: Sorry for the slow turnaround, but it's an aspect of having 200 new e-mails every day. Here's a new version of CGI.pm 2.92 prerelease. Please give it a try on mod_perl1 and mod_perl2 systems. It passes all tests on linux. Hopefully others will test on other platforms. __ 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: CGI.pm and friends port to mp2
Hi Stas, Thanks. I'll fold these changes and release on CPAN. I'll also remove the $|=1 setting, since that was globally needed for FastCGI compatibility, and I don't think that anyone uses it anymore. Lincoln On Monday 10 March 2003 08:43 pm, Stas Bekman wrote: Hi Lincoln, I'm not interested in modifying CGI.pm to use MP2 until I start using MP2 myself. This isn't likely in the near future, since I'm very happy indeed with MP1/Apache1. I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more Apache/compat.pm). I did some basic testing, however it'd be nice if people were to test this patch and confirm that I didn't break anything that did work before. So that Lincoln doesn't have to figure out how to test it. I've attached the diff against 2.91 distro. One more thing, Lincoln, why CGI.pm does: $| = 1; without localizing the change, when running under mod_perl? This has a potentially bad effect on the rest of the modules running under the same server, since now every print() will flush the data. Can this setting be localized (this will probably require to move the unbuffering where it's relevant, rather than globally)? Thanks. __ 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote: Hi Stas, Thanks. I'll fold these changes and release on CPAN. I'll also remove the $|=1 setting, since that was globally needed for FastCGI compatibility, and I don't think that anyone uses it anymore. Lincoln They have came out with a fastcgi (mod_fastcgi-2.4.0) release for httpd-2.0, so you might want to think about that. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if
people could test it on both mod_perl 1 and mod_perl 2, as well as under
normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test suites
aren't exhaustively cover CGI.pm's functionality. So we really need your help
guys to give it a good test in the real apps.
In case anyone wonders why I fiddled with the check for the presence of
modperl, this is because some people write scripts that shell out to
command-line scripts that invoke CGI.pm in order to generate HTML (don't ask
me why). Without the additional checking, CGI.pm sees the MODPERL
environment variable, tries to load mod_perl outside the Apache environment,
and summarily crashes.
Ahm, I'm not quite sure that this does what you say it should:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
because if it's not defined, it'll fall through to the else block, assuming
that the external script is running under mp1. Shouldn't it be:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
if ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
}
also it's probably a good idea to add a note, why this check is done, so not
to forget in the future and optimize it away ;)
I still haven't heard any response as to why I should move to MP2! I wasn't
just being cranky, I'm curious.
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on win32, serialization)
and there is a whole bunch of new functionality available, which will be too
long to list here and partially described on the website.
__
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: CGI.pm and friends port to mp2
Stas Bekman wrote: Lincoln Stein wrote: You want to move to MP2, if one of the following reasons apply: - you are stuck with Apache2 - you want to use i/o filters - you want to write your own protocol handlers - you want to use a threaded mod_perl - you are stuck with win32 (mp1 is unusable on win32, serialization) And you use IPv6 :) Carl
Re: CGI.pm and friends port to mp2
Stas Bekman wrote: Lincoln Stein wrote: Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if people could test it on both mod_perl 1 and mod_perl 2, as well as under normal CGI scripts too ;-) Thanks Lincoln. 'make test' passes with mp1 and mp2 Ah, no it doesn't pass 1.0 tests. I was too quick to post. I've replaced send_cgi_header with direct setting of $r-headers_out without doing the special handling for several headers. I'll revert it to use send_cgi_header. I thought we could get rid of this function, but it's better to keep it. __ 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: CGI.pm and friends port to mp2
Stas Bekman wrote:
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2
Ah, no it doesn't pass 1.0 tests. I was too quick to post. I've replaced
send_cgi_header with direct setting of $r-headers_out without doing the
special handling for several headers. I'll revert it to use
send_cgi_header. I thought we could get rid of this function, but it's
better to keep it.
Here is a new patch. I've attached it as well, in case it gets mangled.
I've also incorporated the defined() fix that I've commented on earlier.
Please check if that's what you meant.
--- /tmp/CGI.pm-2.92/CGI.pm 2003-03-14 06:47:03.0 +1100
+++ /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm 2003-03-14
10:47:05.0 +1100
@@ -173,14 +173,18 @@
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
require mod_perl;
- if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
-$MOD_PERL = 2;
-require Apache::RequestRec;
-require Apache::RequestUtil;
-require APR::Pool;
- } else {
-$MOD_PERL = 1;
-require Apache;
+ # mod_perl handlers may run system() on scripts using CGI.pm
+ # - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
+ if (defined $mod_perl::VERSION) {
+if ($mod_perl::VERSION = 1.99) {
+ $MOD_PERL = 2;
+ require Apache::RequestRec;
+ require Apache::RequestUtil;
+ require APR::Pool;
+} else {
+ $MOD_PERL = 1;
+ require Apache;
+}
}
}
@@ -1320,21 +1324,12 @@
push(@header,map {ucfirst $_} @other);
push(@header,Content-Type: $type) if $type ne '';
- if ($MOD_PERL and not $nph) {
- my $r = Apache-request;
- for (@header) {
- my($k, $v) = split /:\s+/, $_, 2;
- if ($k eq 'Content-Type') {
- $r-content_type($v);
- }
- else {
- $r-headers_out-{$k} = $v;
- }
- }
-$r-send_http_header() if $MOD_PERL == 1;
- return '';
- }
-return join($CRLF,@header).${CRLF}${CRLF};
+my $header = join($CRLF,@header).${CRLF}${CRLF};
+if ($MOD_PERL and not $nph) {
+Apache-request-send_cgi_header($header);
+return '';
+}
+return $header;
}
END_OF_FUNC
__
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
diff
Description: application/java-vm
CGI.pm and friends port to mp2
Hi Lincoln,
I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
myself. This isn't likely in the near future, since I'm very happy indeed
with MP1/Apache1.
I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more
Apache/compat.pm). I did some basic testing, however it'd be nice if people
were to test this patch and confirm that I didn't break anything that did work
before. So that Lincoln doesn't have to figure out how to test it.
I've attached the diff against 2.91 distro.
One more thing, Lincoln, why CGI.pm does:
$| = 1;
without localizing the change, when running under mod_perl? This has a
potentially bad effect on the rest of the modules running under the same
server, since now every print() will flush the data. Can this setting be
localized (this will probably require to move the unbuffering where it's
relevant, rather than globally)?
Thanks.
__
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
--- CGI.pm.orig 2003-03-09 18:29:48.0 +1100
+++ CGI.pm 2003-03-11 12:30:23.0 +1100
@@ -36,6 +36,8 @@
my @SAVED_SYMBOLS;
+$MOD_PERL = 0; # no mod_perl by default
+
# Here are some globals that you might want to adjust
sub initialize_globals {
# Set this to 1 to enable copious autoloader debugging messages
@@ -159,16 +161,17 @@
$IIS++ if defined($ENV{'SERVER_SOFTWARE'}) $ENV{'SERVER_SOFTWARE'}=~/IIS/;
# Turn on special checking for Doug MacEachern's modperl
-if (exists $ENV{'GATEWAY_INTERFACE'}
-
-($MOD_PERL = $ENV{'GATEWAY_INTERFACE'} =~ /^CGI-Perl\//))
- {
+if (exists $ENV{MOD_PERL}) {
$| = 1;
require mod_perl;
if ($mod_perl::VERSION = 1.99) {
- require Apache::compat;
+$MOD_PERL = 2;
+require Apache::RequestRec;
+require Apache::RequestUtil;
+require APR::Pool;
} else {
- require Apache;
+$MOD_PERL = 1;
+require Apache;
}
}
@@ -278,9 +281,15 @@
my($class,$initializer) = @_;
my $self = {};
bless $self,ref $class || $class || $DefaultClass;
-if ($MOD_PERL defined Apache-request) {
- Apache-request-register_cleanup(\CGI::_reset_globals);
- undef $NPH;
+if ($MOD_PERL) {
+my $r = Apache-request;
+if ($MOD_PERL == 1) {
+$r-register_cleanup(\CGI::_reset_globals);
+}
+else {
+$r-pool-cleanup_register(\CGI::_reset_globals);
+}
+undef $NPH;
}
$self-_reset_globals if $PERLEX;
$self-init($initializer);
@@ -1279,13 +1288,21 @@
push(@header,map {ucfirst $_} @other);
push(@header,Content-Type: $type) if $type ne '';
-my $header = join($CRLF,@header).${CRLF}${CRLF};
if ($MOD_PERL and not $nph) {
my $r = Apache-request;
- $r-send_cgi_header($header);
+for (@header) {
+my($k, $v) = split /:\s+/, $_, 2;
+if ($k eq 'Content-Type') {
+$r-content_type($v);
+}
+else {
+$r-headers_out-{$k} = $v;
+}
+}
+ $r-send_http_header() if $MOD_PERL == 1;
return '';
}
-return $header;
+return join($CRLF,@header).${CRLF}${CRLF};
}
END_OF_FUNC
--- CGI/Carp.pm.orig2003-03-11 11:51:28.0 +1100
+++ CGI/Carp.pm 2003-03-11 12:30:02.0 +1100
@@ -358,9 +358,9 @@
# eval. These evals don't count when looking at the stack backtrace.
sub _longmess {
my $message = Carp::longmess();
-my $mod_perl = exists $ENV{MOD_PERL};
-$message =~ s,eval[^\n]+Apache/Registry\.pm.*,,s if $mod_perl;
-return $message;
+$message =~ s,eval[^\n]+(ModPerl|Apache)/Registry\w*\.pm.*,,s
+if exists $ENV{MOD_PERL};
+return $message;
}
sub ineval {
@@ -452,14 +452,25 @@
END
;
-if ($mod_perl (my $r = Apache-request)) {
+if ($mod_perl) {
+require mod_perl;
+if ($mod_perl::VERSION = 1.99) {
+$mod_perl = 2;
+require Apache::RequestRec;
+require Apache::RequestIO;
+require Apache::RequestUtil;
+require APR::Pool;
+require ModPerl::Util;
+require Apache::Response;
+}
+my $r = Apache-request;
# If bytes have already been sent, then
# we print the message out directly.
# Otherwise we make a custom error
# handler to produce the doc for us.
if ($r-bytes_sent) {
$r-print($mess);
- $r-exit;
+ $mod_perl == 2 ? ModPerl::Util::exit(0) : $r-exit;
} else {
$r-status(500);
$r-custom_response(500,$mess);
--- CGI/Pretty.pm.orig 2003-03-11 11:51:47.0
