Re: mod_perl 2.0.0-RC5: make install crashes
Dear Stas, The patch worked, thanks for your help! Harald.
[UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Hi all, Hopefully I didn't overstep any bounds here. At http://p6m7g8.net/Apache-DBI are 3 files http://p6m7g8.net/Apache-DBI/0.94_0.96.patch http://p6m7g8.net/Apache-DBI-0.96.tar.gz http://p6m7g8.net/Apache-DBI/Apache-DBI.ppd This gets Apache::DBI to work nicely with mod_perl2.0RC5 I was going to add some Apache-Test tests using Apache::TestMM (per ask's requests), but I couldn't figure out how not to kill the existing test suites if Apache-Test isn't installed (for mp1 users this will usually be the case as its not in the core mp1 core) Also, I realize AuthDBI version jumped 2 or 3 but I didn't see a reason why they should be different if they are going to be distrubuted together. HTH All feedback appreciated. END -- Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com
Where is CGI.pm 3.08
Hi, http://perl.apache.org/docs/2.0/rename.html states: "If using CGI.pm you will need to upgrade to version 3.08 - versions 3.07 and older do not support the new mod_perl API. you can get CGI.pm from http://search.cpan.org/dist/CGI.pm/."; But I have found only 3.07 there. Thanks, Torsten pgpNRJaq2U8Ks.pgp Description: PGP signature
Re: [mp2] Problems with $r->bytes_sent and $r->status in log handler
On Mon, Apr 18, 2005 at 10:49:10PM +0200, Markus Wichitill wrote: > Hi, > > I have a log handler that is supposed to log whether certain > HTTP-authenticated customers were able to completely download their digital > deliveries. The mod_perl 1.x version works just fine. > > Now under SuSE Linux 9.2/Apache 2.0.53/mod_perl 2.0 RC4, $r->bytes_sent > seems to always contain the full size of the file resource, not the bytes > really sent to the client on an interrupted download. Unless it's a byte > range request, in which case it contains the full size of the range. Does > anybody know whether this is perhaps expected behaviour under Apache2, > maybe a result of its fancy filter architecture? Could it be a mod_perl > bug, or is mod_perl only a thin wrapper around the C structures in this > case, and therefore most likely innocent? Yes, r->bytes_sent is a misnomer, it's just set to the size of the response body in 2.0 as you surmise. IIRC the issue is that buckets from one request may get buffered and not sent during the lifetime of the request, so it's not easy to give a truly accurate count of "bytes sent to the network for this response". I don't know about your r->status issue, if you think this is some mod_ssl issue and can make a C module which reproduces it I'll take a look, preferably filed in bugzilla. Regards, joe
Re: Where is CGI.pm 3.08
Torsten Foertsch wrote: > Hi, > > http://perl.apache.org/docs/2.0/rename.html states: "If using CGI.pm you will > need to upgrade to version 3.08 - versions 3.07 and older do not support the > new mod_perl API. you can get CGI.pm from > http://search.cpan.org/dist/CGI.pm/."; > > But I have found only 3.07 there. please check the archives or your mailbox from yesterday for the answer ;) --Geoff
Re: Web Content Compression FAQ - update
On Mon, 2005-04-18 at 23:08, Scott Gifford wrote: > ... I'm just explaining why the > probably showed up. Right, I hope I've fixed this in POD original for now by joining 'From' line with the previous one. Luckily for me, it was not the beginning of the paragraph... In common case for the future, it would probably be safer to email POD as *.pod.gz file, or inside the *.tar.gz, won't it? Thanks, Slava
Re: Web Content Compression FAQ - update
Slava Bizyayev wrote: On Mon, 2005-04-18 at 23:08, Scott Gifford wrote: ... I'm just explaining why the > probably showed up. Right, I hope I've fixed this in POD original for now by joining 'From' line with the previous one. Luckily for me, it was not the beginning of the paragraph... :) In common case for the future, it would probably be safer to email POD as *.pod.gz file, or inside the *.tar.gz, won't it? Actually, not, as it makes it hard to review and comment on the pod. Normally if the change is not very big it's the best to send a patch as an output of diff(1) against the current pod, in your case: http://perl.apache.org/docs/tutorials/client/compression/compression.pod.orig -- __ 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: [UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Philip M. Gollucci wrote: [...] I was going to add some Apache-Test tests using Apache::TestMM (per ask's requests), but I couldn't figure out how not to kill the existing test suites if Apache-Test isn't installed (for mp1 users this will usually be the case as its not in the core mp1 core) Just require Apache::Test. In the short time to come most Apache modules will use Apache::Test to do the testing anyway. -- __ 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
Implementing abstract URI with mod_perl?
I'm trying to implement abstract URL / URI calls. For my htdocs directory (and .html files), the MultiViews option works fine. For example, http://localhost/address will resolve to its respective html file. No such luck when I'm trying to get Apache to resolve .pl files. For example, http://localhost/perl/counter gives me a 404 error. (The full path, http://localhost/perl/counter.pl, works right) The idea is to hide the .pl extension from average users / links / &c. I've set up a simple Location tag: SetHandler perl-script PerlHandler ModPerl::Registry Options +ExecCGI PerlSendHeader On And it seems like MultiViews option causes problems with the scripts (it denies access / 403 error). Also no luck setting up a typemap / .var file. Any hints? Thanks, Devin Murphy __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Re: [UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Stas Bekman wrote: Philip M. Gollucci wrote: [...] I was going to add some Apache-Test tests using Apache::TestMM (per ask's requests), but I couldn't figure out how not to kill the existing test suites if Apache-Test isn't installed (for mp1 users this will usually be the case as its not in the core mp1 core) Just require Apache::Test. In the short time to come most Apache modules will use Apache::Test to do the testing anyway. Excellent! I'll see what I can come up with. -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Re: [UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Philip M. Gollucci wrote: Hi all, Hopefully I didn't overstep any bounds here. At http://p6m7g8.net/Apache-DBI are 3 files http://p6m7g8.net/Apache-DBI/0.94_0.96.patch http://p6m7g8.net/Apache-DBI-0.96.tar.gz http://p6m7g8.net/Apache-DBI/Apache-DBI.ppd So sorry, http://p6m7g8.net/Apache-DBI-0.96.tar.gz was supposed to be http://p6m7g8.net/Apache-DBI/Apache-DBI-0.96.tar.gz I symlinked it in my site so both should be valid now. -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Re: Implementing abstract URI with mod_perl?
On Tue, 2005-04-19 at 11:30, Devin Murphy wrote: > I'm trying to implement abstract URL / URI calls. > > For my htdocs directory (and .html files), the > MultiViews option works fine. For example, > http://localhost/address will resolve to its > respective html file. > > No such luck when I'm trying to get Apache to resolve > .pl files. For example, http://localhost/perl/counter > gives me a 404 error. (The full path, > http://localhost/perl/counter.pl, works right) > > The idea is to hide the .pl extension from average > users / links / &c. > > I've set up a simple Location tag: > > >SetHandler perl-script >PerlHandler ModPerl::Registry >Options +ExecCGI >PerlSendHeader On > > > And it seems like MultiViews option causes problems > with the scripts (it denies access / 403 error). > > Also no luck setting up a typemap / .var file. > > Any hints? How about fine tuning of mod_rewrite or to write a simple PerlTransHandler? Thanks, Slava
Re: [UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Philip M. Gollucci wrote: > Stas Bekman wrote: > >> Philip M. Gollucci wrote: >> [...] >> >>> I was going to add some Apache-Test tests using Apache::TestMM (per >>> ask's requests), but I couldn't figure out how not to kill the >>> existing test suites if Apache-Test isn't installed (for mp1 users >>> this will usually be the case as its not in the core mp1 core) >> >> >> >> Just require Apache::Test. In the short time to come most Apache >> modules will use Apache::Test to do the testing anyway. >> > Excellent! I'll see what I can come up with. BAH! alright, call me a pain, but I really dislike the idea of lumping test modules in prerequisites - Makefile.PL prerequisites are for modules that are required for the module to operate correctly. the test suite is something else entirely :) see one of my recent Makefile.PL for an idea on how to go about this without requiring Apache-Test, for example http://search.cpan.org/src/GEOFF/Apache-HEADRegistry-0.01/Makefile.PL of course, this is really being academic and there's no reason you can't use PREREQ_PM. but don't let PREREQ_PM lure you into a false sense of security. for example, just finding Apache-Test isn't sufficient to know that mod_perl is available within httpd - you'll want to check for mod_perl.c in your *.t tests and make sure that httpd will always start by using appropriate calls in your config. anyway, not to rant. this is just one of my little nits, is all. but I figure if I can convince people why the runtime environment and testing environment are different in enough different ways people will start to think a bit about why they do what they do and everyone will be better off :) --Geoff
Re: [UPGRADE]: Apache::DBI 0.96 for mod_perl 2.0 RC5
Geoffrey Young wrote: http://search.cpan.org/src/GEOFF/Apache-HEADRegistry-0.01/Makefile.PL of course, this is really being academic and there's no reason you can't use PREREQ_PM. but don't let PREREQ_PM lure you into a false sense of security. for example, just finding Apache-Test isn't sufficient to know that mod_perl is available within httpd - you'll want to check for mod_perl.c in your *.t tests and make sure that httpd will always start by using appropriate calls in your config. Thats pretty crafty... at the moment this is a publicly maintained module, so I'll go with the community thinks is best. I do agree that I didn't want to require Apache-Test with most modules as its _slightly_ bigger then most. -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Apache1/mp1 and Apache2/mp2 on the same machine
Hello, I imagine that this question has been asked before, but my google skills are failing me at the moment. Here's the thing: I have users who would like to keep their apache1/mp1 setup in place while they work on the same machine testing apache2/mp2. When I tried to do a similar thing a month or so ago, I seemed to suffer from "mod_perl1 poisoning": even though I was using Apache2 and mod_perl2, I would get error messages coming from mod_perl1 modules. This was after supplying the MP_INST_APACHE2=1, and I was under the impression that this would let me do exactly what I wanted. This was with RC4. The only way I could fix it was to remove everything from my perl libs that had Apache or mod_perl associations and then reinstall mod_perl2. So, the question is: is it possible (and relatively easy) to have mod_perl1 and mod_perl2 installed on the same machine? Thanks, Scott -- Scott Cain, Ph. D. [EMAIL PROTECTED] GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory
Re: Apache1/mp1 and Apache2/mp2 on the same machine
Sc So, the question is: is it possible (and relatively easy) to have mod_perl1 and mod_perl2 installed on the same machine? Try mod_perl2.00 RC5 seems to work for me :) MP_APACHE2_INST=1 is gone. mod_perl.pm is installed as mod_perl2.pm and mp2 libs are in Apache2:: directory and namespace by default. See this: http://perl.apache.org/docs/2.0/rename.html Thanks, Scott -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Re: Where is CGI.pm 3.08
Geoffrey Young wrote: Torsten Foertsch wrote: Hi, http://perl.apache.org/docs/2.0/rename.html states: "If using CGI.pm you will need to upgrade to version 3.08 - versions 3.07 and older do not support the new mod_perl API. you can get CGI.pm from http://search.cpan.org/dist/CGI.pm/."; But I have found only 3.07 there. please check the archives or your mailbox from yesterday for the answer ;) Geof: We should probably link to your mp2_rename.patch on the rename.html page until 3.08 is released. -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Re: Apache1/mp1 and Apache2/mp2 on the same machine
I did see the rename doc, though I didn't realize that it applied to something as recent as the transition to RC4->RC5. Are you currently using mp1 and mp2? What about any mp applications that were written prior to this name change? Of course, I can't do any testing myself, because I had to blow away my installation of mp1 to get my mp2 apps to work. On Tue, 2005-04-19 at 16:51 -0400, Philip M. Gollucci wrote: > Sc > > >So, the question is: is it possible (and relatively easy) to have > >mod_perl1 and mod_perl2 installed on the same machine? > > > > > Try mod_perl2.00 RC5 seems to work for me :) > > MP_APACHE2_INST=1 is gone. > > mod_perl.pm is installed as mod_perl2.pm > and mp2 libs are in Apache2:: directory and namespace by default. > > See this: > http://perl.apache.org/docs/2.0/rename.html > > >Thanks, > >Scott > > > > > > > > -- Scott Cain, Ph. D. [EMAIL PROTECTED] GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory
Re: Apache1/mp1 and Apache2/mp2 on the same machine
Scott Cain wrote: I did see the rename doc, though I didn't realize that it applied to something as recent as the transition to RC4->RC5. Are you currently using mp1 and mp2? What about any mp applications that were written prior to this name change? Of course, I can't do any testing myself, because I had to blow away my installation of mp1 to get my mp2 apps to work. Yes, I have both mp1 and mp2 installed on my laptop. You'd have to be more specific about applications. Some work some don't :) -- END - Philip M. Gollucci Senior Developer - Liquidity Services Inc. Phone: 202.558.6268 (Direct) E-Mail: [EMAIL PROTECTED] Web:http://www.liquidation.com
Re: Apache1/mp1 and Apache2/mp2 on the same machine
Scott Cain wrote: because I had to blow away my installation of mp1 to get my mp2 apps to work. I always build my servers with their own copy of perl in a directory such as: /usr/local/httpd_20050419 I build a fresh perl and apache in that directory, and get everything working. My particular builds include a separate front end with SSL, and two backends, one each of mod_perl and mod_php. I then use mod_rewrite to send requests to the correct back end. After I have everything working, I then stop and unlink the existing/running apache and then link ln -s /usr/local/httpd_20050419/apache_front /usr/local/apache_front ln -s /usr/local/httpd_20050419/apache_perl /usr/local/apache_perl ln -s /usr/local/httpd_20050419/apache_php /usr/local/apache_php ln -s /usr/local/httpd_20050419/perl/bin/perl /usr/local/bin/perl58xx I can always go back to my previous set-up if I have problems. -- _cliff_rayman_ Business Consulting and Turnaround Management [web] http://www.rayman.com/ [web] http://all-clear-turnaround-management.com/ [eml] cliff _AT_ rayman.com [phn] 888-736-3802 x701 [fax] 818-743-7404 __
Re: Apache1/mp1 and Apache2/mp2 on the same machine
I am using turnkey (http://turnkey.sf.net) which tries to do some fancy
footwork to determine which mod_perl is being used:
(note that Turnkey::Root::mod_perl_version parses $ENV{MOD_PERL} and
returns 2 if it looks like mod_perl 1.99+ or 1 otherwise):
if (Turnkey::Root::mod_perl_version( $ENV{MOD_PERL} ) == 1) {
# do mod_perl1 set up stuff, like:
$STRATEGY_COOKIE = 'Apache::Cookie';
$STRATEGY_REQUEST = 'Apache::Request';
eval qq(
use Apache::Constants qw(:common DECLINED REDIRECT);
use Apache::Request;
use Apache::Cookie;
);
} elsif (Turnkey::Root::mod_perl_version( $ENV{MOD_PERL} ) == 2) {
# do mod_perl2 set up stuff, like:
$STRATEGY_COOKIE = 'CGI::Cookie';
$STRATEGY_REQUEST = 'Apache::RequestRec';
eval qq(
use Apache::Const -compile => qw(:common :http REDIRECT M_GET);
use Apache::RequestUtil;
use APR::Table;
use CGI::Cookie;
use Apache::ParseFormData;
$declined = Apache::DECLINED;
$not_implemented = Apache::HTTP_NOT_IMPLEMENTED;
$m_get = Apache::M_GET;
);
} else {
die("what kind of mod_perl is '".mod_perl_version( $ENV{MOD_PERL} )."'?");
}
Here is Turnkey::Root::mod_perl_version:
BEGIN {
sub mod_perl_version {
my $MOD_PERL_VERSION = shift if @_;
$MOD_PERL_VERSION =~ s/^.*?([\d.]+).*?$/$1/;
eval "require mod_perl";
if($MOD_PERL_VERSION >= 1.99){
$MOD_PERL_VERSION = 2;
} else {
$MOD_PERL_VERSION = 1;
}
return $MOD_PERL_VERSION;
}
}
Is there any reason to believe that would work now as opposed to not
working before? It appeared that before, at least some of the time,
even though I was using Apache2, the mod_perl_version method would
return '1' and muck things up.
Thanks,
Scott
On Tue, 2005-04-19 at 17:11 -0400, Philip M. Gollucci wrote:
> Scott Cain wrote:
>
> >I did see the rename doc, though I didn't realize that it applied to
> >something as recent as the transition to RC4->RC5. Are you currently
> >using mp1 and mp2? What about any mp applications that were written
> >prior to this name change? Of course, I can't do any testing myself,
> >because I had to blow away my installation of mp1 to get my mp2 apps to
> >work.
> >
> >
> Yes, I have both mp1 and mp2 installed on my laptop.
> You'd have to be more specific about applications.
> Some work some don't :)
>
>
--
Scott Cain, Ph. D. [EMAIL PROTECTED]
GMOD Coordinator (http://www.gmod.org/) 216-392-3087
Cold Spring Harbor Laboratory
Re: Apache1/mp1 and Apache2/mp2 on the same machine
That is a great idea and I will use it in the future. Unfortunately, it doesn't really help my users who, while very bright, are not perl developers and would likely balk at doing that. Thanks, Scott On Tue, 2005-04-19 at 14:14 -0700, ___cliff rayman___ wrote: > Scott Cain wrote: > > >because I had to blow away my installation of mp1 to get my mp2 apps to > >work. > > > > > > > > > I always build my servers with their own copy of perl in a directory > such as: > /usr/local/httpd_20050419 > > I build a fresh perl and apache in that directory, and get everything > working. My particular builds include a separate front end with SSL, > and two backends, one each of mod_perl and mod_php. I then use > mod_rewrite to send requests to the correct back end. > > After I have everything working, I then stop and unlink the > existing/running apache and then link > ln -s /usr/local/httpd_20050419/apache_front /usr/local/apache_front > ln -s /usr/local/httpd_20050419/apache_perl /usr/local/apache_perl > ln -s /usr/local/httpd_20050419/apache_php /usr/local/apache_php > ln -s /usr/local/httpd_20050419/perl/bin/perl /usr/local/bin/perl58xx > > I can always go back to my previous set-up if I have problems. > -- Scott Cain, Ph. D. [EMAIL PROTECTED] GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory
Re: Apache1/mp1 and Apache2/mp2 on the same machine
Scott Cain wrote:
I am using turnkey (http://turnkey.sf.net) which tries to do some fancy
footwork to determine which mod_perl is being used:
(note that Turnkey::Root::mod_perl_version parses $ENV{MOD_PERL} and
returns 2 if it looks like mod_perl 1.99+ or 1 otherwise):
Thats not going to run under mp2 RC5+
Its Apache2::Request etc..
It should check $ENV{MOD_PERL_API_VERSION} == 2 to determine if its
running mp2 RC5+
which should be the only version of mp2 it supports until an official
2.0 release is made.
--
END
-
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.558.6268 (Direct)
E-Mail: [EMAIL PROTECTED]
Web:http://www.liquidation.com
Re: Apache1/mp1 and Apache2/mp2 on the same machine
On Tue, 2005-04-19 at 17:21 -0400, Scott Cain wrote: > That is a great idea and I will use it in the future. Unfortunately, it > doesn't really help my users who, while very bright, are not perl > developers and would likely balk at doing that. I do something similar to what Cliff has here. There's nothing special for the users to know except the URL of the server they want to talk to. You already need to install a separate apache for mod_perl 2 anyway, so installing a separate perl doesn't seem like a big extra to me, although technically it is not needed for many things anymore now that modules go into the Apache2:: namespace. I prefer to have a separate perl so that I know for certain which modules I'm using and can port things without breaking the existing code. - Perrin
Re: Apache1/mp1 and Apache2/mp2 on the same machine
Philip,
Thanks! That is very useful info--I will forward it to the turnkey
developers (it's not my project, just related to one I am working on).
Scott
On Tue, 2005-04-19 at 17:26 -0400, Philip M. Gollucci wrote:
> Scott Cain wrote:
>
> >I am using turnkey (http://turnkey.sf.net) which tries to do some fancy
> >footwork to determine which mod_perl is being used:
> >
> >(note that Turnkey::Root::mod_perl_version parses $ENV{MOD_PERL} and
> >returns 2 if it looks like mod_perl 1.99+ or 1 otherwise):
> >
> >
> Thats not going to run under mp2 RC5+
> Its Apache2::Request etc..
>
> It should check $ENV{MOD_PERL_API_VERSION} == 2 to determine if its
> running mp2 RC5+
> which should be the only version of mp2 it supports until an official
> 2.0 release is made.
>
--
Scott Cain, Ph. D. [EMAIL PROTECTED]
GMOD Coordinator (http://www.gmod.org/) 216-392-3087
Cold Spring Harbor Laboratory
Re: Apache1/mp1 and Apache2/mp2 on the same machine
That's a good point. I will at least suggest it to them. Scott On Tue, 2005-04-19 at 17:37 -0400, Perrin Harkins wrote: > On Tue, 2005-04-19 at 17:21 -0400, Scott Cain wrote: > > That is a great idea and I will use it in the future. Unfortunately, it > > doesn't really help my users who, while very bright, are not perl > > developers and would likely balk at doing that. > > I do something similar to what Cliff has here. There's nothing special > for the users to know except the URL of the server they want to talk to. > > You already need to install a separate apache for mod_perl 2 anyway, so > installing a separate perl doesn't seem like a big extra to me, although > technically it is not needed for many things anymore now that modules go > into the Apache2:: namespace. I prefer to have a separate perl so that > I know for certain which modules I'm using and can port things without > breaking the existing code. > > - Perrin > > -- Scott Cain, Ph. D. [EMAIL PROTECTED] GMOD Coordinator (http://www.gmod.org/) 216-392-3087 Cold Spring Harbor Laboratory
