You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/11 02:43:20 UTC
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Posted by Brian P Millett <bp...@ec-group.com>.
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."
bpm@ec-group.com Greg Glenn
Re: Does perl have Failover with Open Source Web Platforms?
Posted by Perrin Harkins <pe...@elem.com>.
Richard Heintze wrote:
> He needs declarative role based authorization and
> authentication for his web site -- and maybe fault
> tolerance too depending on the price of the hardware
> for a linux server.
These are two separate things.
Authen/Authz can be implemented any way you like on mod_perl. It does
not impose an application structure. If you want an already built
implementation, you could look at some of the many auth modules on CPAN
or at OpenInteract which includes a user/group security model.
For the CPAN list, start here:
http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW
and look at the PerlAuthenHandler and PerlAuthzHandler modules.
For failover, the question is what are you failing over? Any old
load-balancer will give you failover between machines. Failing over
your data is a matter of how you implement your application. I believe
JBoss fails over session data. You get the same result with mod_perl if
you store your session data in a database, using something like
Apache::Session.
> Also, what are your favorite hardware vendors for
> linux clusters?
Red Hat sells a software failover system that you can use, but most
people just use a load-balancing switch like big/ip for this. No
special hardware or software is required for that.
- Perrin
Re: Does perl have Failover with Open Source Web Platforms?
Posted by Jay Thorne <yo...@userfriendly.org>.
On March 13, 2003 11:48 am, Richard Heintze wrote:
> My client is partial to perl so I installed mod_perl
> on Apache HTTPD on his windows servers.
>
> Now, however, he wants to price a linux cluster with
> raid to replace his windows servers.
>
> He needs declarative role based authorization and
> authentication for his web site -- and maybe fault
> tolerance too depending on the price of the hardware
> for a linux server.
>
> JBoss is cheap and open source with these features.
And its java and may not perform as well as well formed mod_perl, but I'm
probably opining from my impressions based on BEA on slowlaris compared to
mod_perl on linux.
> My client, however, is partial to perl. How can we get
> perl with failover on a linux cluster?
Lots of different ways. Depends on where you want the failover;
If a 30 second delay is acceptable, even round robin dns forms a type of
failover. If the first ip fails, the browser tries the second, etc.
Then you separate application server from db, and put the db on some kind of
redundancy/failover; like a app level retry list, a OS level failover, with
proxy ARP and whatever to minimize downtime etc.
An overview of OS level failover on linux:
http://www.linuxvirtualserver.org/Documents.html
So in summary, failover is a big fat word with lots of meaning.
The faster you want it, the more money you spend. A 30 second failover was
good enough for me, so I used round robin dns. Your mileage my vary.
> Also, what are your favorite hardware vendors for
> linux clusters?
Whitebox hardware with name brand components, but I'm cheap.
This is another question that is too broad. What level of service do you
require? My local clone shop knows dick about linux but is happy to sell me
machines with no OS loaded. You may want Scyld.com or one of the other
cluster specialists if you are talking getting vendor expertise. They tend to
focus on compute clusters, not web.
--
Jay "yohimbe" Thorne yohimbe@userfriendly.org
Mgr Sys & Tech, Userfriendly.org
Does perl have Failover with Open Source Web Platforms?
Posted by Richard Heintze <si...@yahoo.com>.
My client is partial to perl so I installed mod_perl
on Apache HTTPD on his windows servers.
Now, however, he wants to price a linux cluster with
raid to replace his windows servers.
He needs declarative role based authorization and
authentication for his web site -- and maybe fault
tolerance too depending on the price of the hardware
for a linux server.
JBoss is cheap and open source with these features.
My client, however, is partial to perl. How can we get
perl with failover on a linux cluster?
Also, what are your favorite hardware vendors for
linux clusters?
Thanks,
Siegfried
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: CGI.pm and friends port to mp2
Posted by Lincoln Stein <ls...@cshl.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: CGI.pm and friends port to mp2
Posted by Lincoln Stein <ls...@cshl.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: CGI.pm and friends port to mp2
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Posted by Lincoln Stein <ls...@cshl.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: CGI.pm and friends port to mp2
Posted by Colin Kuskie <ck...@dalsemi.com>.
On Fri, Mar 14, 2003 at 10:31:25AM +1100, Carl Brewer wrote:
>
>
> 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 :)
Or use Red Hat, due to the new forced upgrade cycle. In October (when
they stop making upgrades for 7.x), a significant chunk of the Linux
world is going to:
1) Stop using Red Hat
2) Compile their own upgrades
3) Start using Red Hat 8
Colin
Re: CGI.pm and friends port to mp2
Posted by Carl Brewer <ca...@bl.echidna.id.au>.
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: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
I suppose there might be name clashes, but I'll look into doing that.
Lincoln
On Monday 24 March 2003 07:08 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>How about making CGI.pm a subclass of $r? (optionally of course, by
> >>dynamically changing @ISA), so instead of returning $q it'll return $r,
> >>after re-blessing it.
> >
> > Sounds interesting. What would be the advantage of that?
>
> The advantage is that
> - you don't have to keep around two instances: $r and $q.
> - assuming that CGI.pm-specific code is not used one can transparently
> switch between Apache::Request and CGI.pm, by just changing:
>
> $r = Apache::Request->new($r);
> $r = CGI->new($r);
>
> And of course Apache::Request is a subclass of Apache ($r) and it works
> pretty well.
>
> In the future I can see someone extending Apache::Request to handle
> CGI.pm's HTML generation in C, so the two could be replace each other.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: the deprecation of Apache->request in mp2
Posted by Andrew Ho <an...@tellme.com>.
Hello,
NT>I sure hope not! I second John Siracusa's post on this. Keep the HTML
NT>generation well away from request parsing, please!
I personally am 100% in the camp of keeping HTML generation separate from
quest parsing, but I do recognize the advantage of having API level
compatibility between Apache::Request and CGI, so that you could switch
from one to another easily. I think this would be a big win for mod_perl
overall from the "port your scripts quickly" point of view.
I think a good compromise would be to keep the HTML generation code in an
entirely separate module, like Apache::Request::HTML or something. That
class could augment Apache::Request with new methods. (This is somewhat
similar to how Apache::File and Apache::Log augment the Apache class with
new methods.)
This seems to satisfy both sides, and accomplish the laudable goal of
making CGI and Apache::Request API compatible without bloating up the
normal use of Apache::Request.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer 1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
----------------------------------------------------------------------
Re: the deprecation of Apache->request in mp2
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Tue, 25 Mar 2003, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>How about making CGI.pm a subclass of $r? (optionally of course, by
> >>dynamically changing @ISA), so instead of returning $q it'll return $r,
> >>after re-blessing it.
> >
> >
> > Sounds interesting. What would be the advantage of that?
>
> The advantage is that
> - you don't have to keep around two instances: $r and $q.
> - assuming that CGI.pm-specific code is not used one can transparently switch
> between Apache::Request and CGI.pm, by just changing:
>
> $r = Apache::Request->new($r);
> $r = CGI->new($r);
>
> And of course Apache::Request is a subclass of Apache ($r) and it works pretty
> well.
>
> In the future I can see someone extending Apache::Request to handle CGI.pm's
> HTML generation in C, so the two could be replace each other.
I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well away from request parsing, please!
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: the deprecation of Apache->request in mp2
Posted by John Siracusa <si...@mindspring.com>.
On 3/24/03 7:08 PM, Stas Bekman wrote:
> In the future I can see someone extending Apache::Request to handle CGI.pm's
> HTML generation in C, so the two could be replace each other.
I've always thought that HTML generation does not belong in CGI.pm, so I
don't see duplicating that functionality in an extended $r as a useful goal.
Better to separate the HTML stuff (preferably into HTML widget objects, IMO)
from request parsing and response formulation and delivery.
-John
Re: the deprecation of Apache->request in mp2
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
>>How about making CGI.pm a subclass of $r? (optionally of course, by
>>dynamically changing @ISA), so instead of returning $q it'll return $r,
>>after re-blessing it.
>
>
> Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request->new($r);
$r = CGI->new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well.
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
> How about making CGI.pm a subclass of $r? (optionally of course, by
> dynamically changing @ISA), so instead of returning $q it'll return $r,
> after re-blessing it.
Sounds interesting. What would be the advantage of that?
Lincoln
>
> > The other issue is that it will only work with the OO form of CGI, which
> > many people (including myself) don't use.
>
> You can still have an accessor function to set $r:
>
> use CGI;
> CGI->r($r);
>
> > I would prefer a more transparent way to obtain the current request. Is
> > there no low-overhead way of getting at this?
>
> Not, under threaded mpm. Since the code should work the same with threaded
> and non-threaded mpm, it's a problem for any 2.0 code. The problem with
> Apache->request is that it involves storing and retrieving data from the
> TLS (thread local storage), which is slow. So while the functionality is
> there, sites that are looking for high performance will want to pass $r,
> rather than rely on Apache->request.
>
> Of course one can argue, that sites looking for high performance should use
> Apache::Request (which is not quite there yet, for 2.0). So if this
> argument is valid and you don't feel like changing the API, that's cool
> too. May be in the future.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: the deprecation of Apache->request in mp2
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> I can do this (changing the new() call to accept $r). My understanding is
> that client code will need to be changed to take advantage of this, right?
That's correct. $r should be explicitly passed. However the CGI-side code
doesn't have to specific to mod_perl 2.0. CGI should be able to do that with
either version of mod_perl. In this case the user code can be ported to work
with both versions of mod_perl.
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r, after
re-blessing it.
> The other issue is that it will only work with the OO form of CGI, which many
> people (including myself) don't use.
You can still have an accessor function to set $r:
use CGI;
CGI->r($r);
> I would prefer a more transparent way to obtain the current request. Is there
> no low-overhead way of getting at this?
Not, under threaded mpm. Since the code should work the same with threaded and
non-threaded mpm, it's a problem for any 2.0 code. The problem with
Apache->request is that it involves storing and retrieving data from the TLS
(thread local storage), which is slow. So while the functionality is there,
sites that are looking for high performance will want to pass $r, rather than
rely on Apache->request.
Of course one can argue, that sites looking for high performance should use
Apache::Request (which is not quite there yet, for 2.0). So if this argument
is valid and you don't feel like changing the API, that's cool too. May be in
the future.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: the deprecation of Apache->request in mp2
Posted by Lincoln Stein <ls...@cshl.org>.
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
The other issue is that it will only work with the OO form of CGI, which many
people (including myself) don't use.
I would prefer a more transparent way to obtain the current request. Is there
no low-overhead way of getting at this?
Lincoln
On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote:
> One more issue with CGI.pm and mp2, and other modules as well.
>
> CGI.pm is using Apache->request. The setting/retrieval of the global
> request record under threads is expensive, so the use of Apache->request is
> deprecated in mp2.
>
> If CGI.pm can be changed to optionally accept $r (as an argument to new(),
> plus a special accessor to set later) and use it instead, this will improve
> the performance if Apache->request is not set.
>
> Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by
> default with 'SetHandler perl-script') that is half of the performance hit
> (store), and the actual use of Apache->request (get) is the second half.
>
> See:
> http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque
>st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: CGI.pm and friends port to mp2
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Posted by Stas Bekman <st...@stason.org>.
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.000000000 +1100
+++ /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm 2003-03-14
10:47:05.000000000 +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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
the deprecation of Apache->request in mp2
Posted by Stas Bekman <st...@stason.org>.
One more issue with CGI.pm and mp2, and other modules as well.
CGI.pm is using Apache->request. The setting/retrieval of the global request
record under threads is expensive, so the use of Apache->request is deprecated
in mp2.
If CGI.pm can be changed to optionally accept $r (as an argument to new(),
plus a special accessor to set later) and use it instead, this will improve
the performance if Apache->request is not set.
Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by
default with 'SetHandler perl-script') that is half of the performance hit
(store), and the actual use of Apache->request (get) is the second half.
See:
http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_request_
http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com