Re: Starting out with mod_perl
Hi!
On Tue, Dec 16, 2003 at 12:36:43PM -0800, Maurice Height wrote:
> I am coding a web application using lots of Perl modules including
> Class::DBI, Text::MagicTemplate, CGI::Session and CGI::Application via
> ActivePerl v5.8.1.807. My code has to run on both Win2K and WinXP together
> ..
> Should I use mod_perl v1 or v2?
As you are using Windows, mod_perl 1.x isn't really an option, as Windows
doesn't support forking (at least that's my understanding, I never tried
running Apache on Win)
So you should go with mod_perl 2.x
> I was thinking of using Apache::Request to process form data,
> Apache::Cookie, Apache::DBI for persistent db connections and something for
> user authorization. I understand libapreq contains the first two modules.
>
> Is this available for mod_perl2?
Sort of, but somebody with mod_perl 2 experience should be able to tell you
more on this issue.
> BTW I put all the perl modules that my application uses (except my own) in a
> startup.pl file and added a PerlRequire directive to httpd.conf. This
> increased instances of Apache.exe from about 4 - 8 MB to about 23 - 26 MB!
>
> Is this normal?
Again, I'm running mod_perl on Linux, but it definitly is normal to get
quite a huge increase in memory usage. See
http://perl.apache.org/docs/1.0/guide/performance.html
for more (mod_perl 1 related) info, or (mod_perl2):
http://perl.apache.org/docs/2.0/user/performance/prevent.html
http://perl.apache.org/docs/2.0/user/performance/mpm.html
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Data lost when browser refreshed
Hi there, On 15 Dec 2003, Perrin Harkins wrote: > On Mon, 2003-12-15 at 18:58, Tom Conway wrote: > > I'm using RH8 and have the latest rpm. > > Newer source rpms (non-redhat) won't compile because of dependencies. > > Red Hat doesn't support that version anymore, do they? Sounds like you > need to either upgrade, learn how to build your own RPMs, or compile > without an RPM. Many people build their own RPMs for internal use, so > that would be a good route to take. Unless you are very comfortable with system hacking I would caution against upgrading from RH8 to RH9 just to get the latest mod_perl, as there are numerous other changes which would demand your attention. Compiling from the latest sources would be my choice. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: BUG?: POST/GET data loss
On Thu, 11 Dec 2003, Volker Kroll wrote: > On Wed, 2003-12-10 at 11:38, Hakan Nilsson wrote: > > > Thanks for your input Volker, but we don't care if it is POST or GET that > > is used. Most often we have links like > > > > A link! > > > > which sometimes work and sometimes fails > > > > To you that have the same problem (Jason Chinnes I think it was?): > > > > What do you do to 'solve' it? We restart the apache at short intervals (a > > few hours) and that seems to more or less solve it. At least it doesn't > > happen as often. > > Are there any messages in the error_log? It is not often, that errors > happen without some info in the logs. Is it possible, that the instance > of the apache, which serves the request segfaults and the reload gives > you the next instance? > > Regards > Volker Nopes, no messages in any error_log. The access_log says everything is ok and when I check the process id's of the apache childs (via top or whatever) nothing happens there either. It can hardly be segfaults or such since at a test system that had been up and running for a month or so I got one correct answer out of every tenth reload I did, the rest returned the page as if I had given it no arguments. Regards, Hakan - Håkan Nilsson Futurize AB -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Can't read in RAW_ARGS
Hi there, On Mon, 15 Dec 2003, Alexey Zayats wrote: > time to rewrite my mod_perl application. > [snip, snip] > Every parsing methods, such as TAKE1, TAKE2 etc., works fine. It would have been enormously helpful if you had said you were working through the examples in Chapter 8 of the Eagle Book. > While i try read config handle i've got > "readline() on unopened filehandle _GEN_0 at ..." Perhaps a filehandle has something wrong with it? You could always insert some print statements to debug it, see the debugging section of the mod_perl guide for more information. As a general rule, please do not assume that we already know things about your installation or what you are doing. Explain it. Please also make sure that the code you post in your message is *exactly* the same as the code which is giving you trouble. I am not saying that it is or it is not in this case, but I am wondering... :) 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Status erroneously reports error
Setup: mod_perl-1.99_11, libapreq2-2.02, Apache 2.0.47, RedHat 9.
Running Apache::Status gives the attached output. There's no trace
of an error in the logs & I'm guessing that it's just an inappropriate
return code.
I _think_ this might be an appropriate patch?
--- Apache/Status.pm.orig2003-11-13 22:56:50.0 +
+++ Apache/Status.pm2003-12-16 13:11:40.0 +
@@ -19,6 +19,7 @@
$Apache::Status::VERSION = '3.00'; # mod_perl 2.0
use constant IS_WIN32 => ($^O eq "MSWin32");
+use Apache::Const -compile => qw(OK);
our $newQ;
@@ -135,7 +136,7 @@
}
$r->print("");
-1;
+return Apache::OK;
}
sub header {
Title: Apache::Status
Embedded Perl version v5.8.0 for Apache/2.0.47 (Fedora) process 16322,
running since Tue Dec 16 12:02:22 2003
PerlRequire'd Files
Perl Configuration
Compiled Registry Scripts
Environment
ISA Tree
Symbol Table Dump
Loaded Modules
Inheritance Tree
Signal Handlers
OK
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.
More information about this error may be available
in the server error log.
Apache/2.0.47 (Fedora) Server at localhost Port 80
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Data lost when browser refreshed
I agree, I setup a test machine and I did the rh9 upgrade and it trashed the rpm's I had created from source (ssh, samba). They had to be redownloaded and rebuilt. Any customizing gets messed up. I also tried installing apache from source successfully with mod_perl but I had to leave both the redhat and source versions on the machine. I just don't have the time to deal with these changes now and I worry about dependencies. I'm considering a full source install of something like Gentoo, but again, I need to try it out on the test machine. It's nothing that helps my immeadiate situation. I'll have to stick with vanilla perl/cgi for now, not a bad option. Thanks, Tom Original Message Follows From: Ged Haywood <[EMAIL PROTECTED]> To: Perrin Harkins <[EMAIL PROTECTED]> CC: Tom Conway <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Data lost when browser refreshed Date: Tue, 16 Dec 2003 09:17:44 + (GMT) Hi there, On 15 Dec 2003, Perrin Harkins wrote: > On Mon, 2003-12-15 at 18:58, Tom Conway wrote: > > I'm using RH8 and have the latest rpm. > > Newer source rpms (non-redhat) won't compile because of dependencies. > > Red Hat doesn't support that version anymore, do they? Sounds like you > need to either upgrade, learn how to build your own RPMs, or compile > without an RPM. Many people build their own RPMs for internal use, so > that would be a good route to take. Unless you are very comfortable with system hacking I would caution against upgrading from RH8 to RH9 just to get the latest mod_perl, as there are numerous other changes which would demand your attention. Compiling from the latest sources would be my choice. 73, Ged. _ Cell phone switch rules are taking effect find out more here. http://special.msn.com/msnbc/consumeradvocate.armx -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Can't read in RAW_ARGS
Hi, Ged. Thanks a lot and excuse me. Work been stoped at some time, but your message took me to go on. mod_perl compiled as dso throw apxs: perl Makefile.PL \ > USE_APXS=1 \ > WITH_APXS=/usr/sbin/apxs \ > EVERYTHING=1 I'll try to solve problem on my own and when i use code example from "Chapter 9 - Perl API Reference Guide" of Eagle Book, i've got it working. instead of: while((my $line = <$fh>) !~ m:^$EndTiken:) use a: while($parms->getline($line)) And every is fine. But readline globe (<$fh>) still not working. And that not need me at that time. Sorry for take your time. If interesting, take to http://engine.suse-linux.kubic.ru/ Alexis Zayats. __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Starting out with mod_perl
On Tue, 16 Dec 2003, Thomas Klausner wrote: > Hi! > > On Tue, Dec 16, 2003 at 12:36:43PM -0800, Maurice Height wrote: > > > I am coding a web application using lots of Perl modules > > including Class::DBI, Text::MagicTemplate, CGI::Session > > and CGI::Application via ActivePerl v5.8.1.807. My code > > has to run on both Win2K and WinXP together .. Should I > > use mod_perl v1 or v2? > > As you are using Windows, mod_perl 1.x isn't really an > option, as Windows doesn't support forking (at least > that's my understanding, I never tried running Apache on > Win) > > So you should go with mod_perl 2.x I'd second that ... The Win32 section of the mod_perl 1 docs at http://perl.apache.org/ have a more detailed discussion on what the limitations of mod_perl 1 on Win32 are. So although mod_perl 2 isn't as mature as mod_perl 1, for many people the benefits of mod_perl 2 (and Apache 2) on Win32 outweigh this disadvantage. Note that, on Win32, mod_perl 2 requires perl-5.8.0 or greater (ie, an ActivePerl build in the 8xx series). > > I was thinking of using Apache::Request to process form > > data, Apache::Cookie, Apache::DBI for persistent db > > connections and something for user authorization. I > > understand libapreq contains the first two modules. > > > > Is this available for mod_perl2? > > Sort of, but somebody with mod_perl 2 experience should be > able to tell you more on this issue. There's a development release of libapreq2 available for use with Apache/2 - see http://httpd.apache.org/apreq/. For Win32 there's an associated ppm package at http://theoryx5.uwinnipeg.ca/ppms/libapreq2.ppd. However, be aware that this is a developer's release, and isn't yet intended for production work. -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Problems with Multiple PerlTransHandlers
Hi all,
I'm having some problems when I have with multiple PerlTransHandlers
defined.
What is happening is even if one handler returns OK, the other ones are
still invoked. Also, the result changes depending on the order in which
the handlers are set. This should not have any impact since each handler
uses if ($uri =~ /^.../){...} on distinct paths, so therefore only 1
handler actually does someting per URI.
I was able to get around this by creating a meta handler as such:
PerlTransHandlerApache::ASP::MetaTransHandler
PerlSetVar MetaTransHandlerMap "\
/secure/=> Apache::ASP::Cascade, \
/reports/ => Apache::ASP::ReportProxy, \
/rimages/ => Apache::ASP::ReportProxy"
that dispatches the request to the proper handler, but this still
bothers me since the documentation and book state that what I was
originally tring to do should work ok.
Has anyone succesfully used multiple PerlTransHandlers?
Is there anyway to "localize" (i.e. ) them so that they are
not always invoked?
Anyways here's my configuration:
mod_perl-1.26-5
apache-1.3.27-3
This is perl, v5.6.1 built for i386-linux
Red Hat Linux release 7.3 (Valhalla)
Thanks,
--
=
Patrick LeBoutillier
Laval, Québec, Canada
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Status erroneously reports error
Paul Flinders wrote:
Setup: mod_perl-1.99_11, libapreq2-2.02, Apache 2.0.47, RedHat 9.
Running Apache::Status gives the attached output. There's no trace
of an error in the logs & I'm guessing that it's just an inappropriate
return code.
I _think_ this might be an appropriate patch?
--- Apache/Status.pm.orig2003-11-13 22:56:50.0 +
+++ Apache/Status.pm2003-12-16 13:11:40.0 +
@@ -19,6 +19,7 @@
$Apache::Status::VERSION = '3.00'; # mod_perl 2.0
use constant IS_WIN32 => ($^O eq "MSWin32");
+use Apache::Const -compile => qw(OK);
our $newQ;
@@ -135,7 +136,7 @@
}
$r->print("");
-1;
+return Apache::OK;
}
sub header {
Thanks Paul,
That has already been fixed in the cvs version:
Fix Apache::Status::handler to return 'Apache::OK' [Juanma Barranquero
<[EMAIL PROTECTED]>]
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Request->instance(undef)
If you call Apache::Request->instance with an undefined value, it dies when it tries to call pnotes() on that argument. It seems to me that it should simply return a false value if given undef. This can happen if you have a piece of code like this: my $r = Apache::Request->instance(Apache->request); which may be called during server startup or during a request. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
use vars question
I'm still a little unclear after reading the appropriate perl docs, or maybe just want to make sure I understand it correctly. If I declare some package globals with use vars(), will the values be persistant in mod_perl, or will they go undefined after the code is done executing? Chris -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: use vars question
Chris Ochs wrote: I'm still a little unclear after reading the appropriate perl docs, or maybe just want to make sure I understand it correctly. It usually helps to tell what appropriate docs have you read. http://perl.apache.org/docs/1.0/guide/porting.html#Global_Variables_Persistence It's also mentioned in several places at: http://perl.apache.org/docs/general/perl_reference/perl_reference.html Brian has patched recently this docs explaining how to use 'local our' to have globals automatically getting undefined at the end of the enclosing scope. http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remedies_for_Inner_Subroutines If I declare some package globals with use vars(), will the values be persistant in mod_perl, or will they go undefined after the code is done executing? persistent, yes. Undefined, no. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: use vars question
Hi there, On Tue, 16 Dec 2003, Chris Ochs wrote: > If I declare some package globals with use vars(), will the values be > persistant in mod_perl, or will they go undefined after the code is done > executing? They are global, so they persist until the death of the interpreter which executed those statements - in mod_perl version 1, that means when a mod_perl Apache child dies. Globals can be a pain in mod_perl. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[OT] Re: [Fun] telecommute job
I can't understand the point of your messages to this list. 1 - I see nothing funny at all. 2 - As you said in your 1st message, you don't have enought perl knowledge to get the job as XSLT was one required pont to the job. 3 - You sent your CV in MS Word format. Most higher technical related companies reject ms word CV from the candidates. Most delete the email without reading the attachment. 4 - You demonstrated to be clueless and/or rude with other people. 5 - I have no clue what you call a XMa's Miracle. 6 - THIS IS COMPLETE OFF-TOPIC!!! Please let's end this thread right here and keep this list with MOD PERL related issues only. []'s Raul Dias On Thu, 2003-12-11 at 23:54, Slava Bizyayev wrote: > I've been recently looking for a telecommute job in order to provide > some Christmas support to my family. Obviously, I tried one ad from the > Perl Telecommuting Job List. Negotiations took not a long time. Full > content is attached. Especially, I would stress the funny way that > Laurie J. Roth - Director of Search & Consulting - used to answer my > innocent question. Enjoy: > > - > > > -Original Message- > > From: Slava Bizyayev [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 10, 2003 11:32 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Sr. Perl Developer > > > > > > Dear Sir/Lady, > > > > I have no XSLT experience. Other your requirements are OK. My resume > is > > attached in MS Word format. Please let me know if you would like to > > talk. > > > > Sincerely, > > Slava (Vyacheslav) Bizyayev > > > > On Thu, 2003-12-11 at 08:39, Laurie Roth wrote: > > Slava, > > > > Thank you for sending your resume along, however, my client wants 4 > solid > > years of perl development. They are really looking for a Perl guru. > Good > > luck! > > > > Laurie J. Roth > > Director of Search & Consulting > > 561-347-6421 ext:215 > > mailto:[EMAIL PROTECTED] > > > > -Original Message- > From: Slava Bizyayev [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 11, 2003 3:55 PM > To: Laurie Roth > Subject: RE: Sr. Perl Developer > > > Are you idiot? > > Regards, > Slava > > > > > From: > Laurie Roth > <[EMAIL PROTECTED]> >To: > Slava > Bizyayev > <[EMAIL PROTECTED]> > Subject: > RE: Sr. Perl > Developer > Date: > Thu, 11 Dec > 2003 > 16:08:07 > -0500 > > I must have read another resume when I responded. I apologize for the > confusion. Your people skills are horrific and I could never consider > you > for an opportunity with any of my clients. > > Laurie J. Roth > Director of Search & Consulting > 561-347-6421 ext:215 > mailto:[EMAIL PROTECTED] > > - > > Happy Christmas to everyone, > > Slava > > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: use vars question
Thanks I reread the last link and noticed what I didnt' see before. Now my next question... I use the following to access the cgi vars.. %Q = $r->method eq 'POST' ? $r->content : $r->args; If I make %Q a package global, will the above line re initialize %Q every time the program is run, or do I need to do some kind of foreach iteration through %Q and undefine everything first? - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Chris Ochs" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, December 16, 2003 10:32 AM Subject: Re: use vars question > Chris Ochs wrote: > > I'm still a little unclear after reading the appropriate perl docs, or maybe > > just want to make sure I understand it correctly. > > It usually helps to tell what appropriate docs have you read. > http://perl.apache.org/docs/1.0/guide/porting.html#Global_Variables_Persistence > > It's also mentioned in several places at: > http://perl.apache.org/docs/general/perl_reference/perl_reference.html > > Brian has patched recently this docs explaining how to use 'local our' to have > globals automatically getting undefined at the end of the enclosing scope. > http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remedies_for_Inner_Subroutines > > > If I declare some package globals with use vars(), will the values be > > persistant in mod_perl, or will they go undefined after the code is done > > executing? > > persistent, yes. Undefined, no. > > __ > 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 > > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Clearing globals
Will this work to undefine everything in package Test ?
sub ClearGlobals {
my $globalspace = "Test";
foreach (keys %{"${globalspace}::"}) {
unless ($_ eq 'dbh') { ## Don't undef the cached database handle!
local *symbol = "${globalspace}::${_}";
undef $symbol;
undef @symbol;
undef %symbol;
}
}
}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [OT] Re: [Fun] telecommute job
On Tue, Dec 16, 2003 at 04:35:46PM -0200, Raul Dias wrote: > I can't understand the point of your messages to this list. > > 1 - I see nothing funny at all. The point, clearly, was to attempt to be funny; the actual interchange almost certainly never took place. It failed, though, and I was hoping the poster would catch on that no one realised he was a troll on the first round, last week. Please Don't Feed The Trolls. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://baylink.pitas.com +1 727 647 1274 Come see Linux Gazette in our new home: www.linuxgazette.net! -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: use vars question
Chris Ochs wrote: Thanks I reread the last link and noticed what I didnt' see before. Now my next question... I use the following to access the cgi vars.. %Q = $r->method eq 'POST' ? $r->content : $r->args; If I make %Q a package global, will the above line re initialize %Q every time the program is run, or do I need to do some kind of foreach iteration through %Q and undefine everything first? As long as you make sure that you always run the above code before you use %Q, then yes, you are all set. As repeated several times on this list using Apache::Singleton or Class::Singleton or writing your own, is a more robust solution than plain globals. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Clearing globals
Chris Ochs wrote:
Will this work to undefine everything in package Test ?
sub ClearGlobals {
my $globalspace = "Test";
foreach (keys %{"${globalspace}::"}) {
unless ($_ eq 'dbh') { ## Don't undef the cached database handle!
local *symbol = "${globalspace}::${_}";
undef $symbol;
undef @symbol;
undef %symbol;
}
}
}
This is quite dangerous, as you may undef things you didn't create. (e.g. some
3rd party module may use the same package for its own things). A better
approach is to explicitly undef only things that you created. But again, you
won't need that when using Singleton, which can contain all the "globals" now
as private vars and you can nuke it at once.
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Proxy Directive and PerlSetOutputFilter
Hi, At the moment I'm playing around a little bit with filters. When I define in httpd.conf an entry a la: SetOutputFilter bladibla The filter works. But when I do something like: PerlSetOutputFilter Apache::bladibla it doesn't. However when I remove the Proxy directive a la: # PerlSetOutputFilter Apache::bladibla # the Apache::bladibla filter works just fine (only for all sites and that is not what I'm looking for. I just want to modify the content of www.xyz.com). How can I resolve this? I'm using Apache 2.0.48 and mod_perl 1.99_11 Sincerely, Erick -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Proxy Directive and PerlSetOutputFilter
Erick Staal wrote: Hi, At the moment I'm playing around a little bit with filters. When I define in httpd.conf an entry a la: SetOutputFilter bladibla The filter works. But when I do something like: PerlSetOutputFilter Apache::bladibla it doesn't. But the two aren't the same (look at the proxy settings). Does SetOutputFilter bladibla work? I think the filter may need to be a connection filter for it to work for Proxy. I haven't tried this setup yet, so I'm just guessing here. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems with Multiple PerlTransHandlers
Patrick LeBoutillier wrote: > Hi all, > > I'm having some problems when I have with multiple PerlTransHandlers > defined. > > What is happening is even if one handler returns OK, the other ones are > still invoked. yes, this is a known issue. it's fixed in 2.0 but the behavior in 1.3 isn't likely to change. > this still > bothers me since the documentation and book state that what I was > originally tring to do should work ok. yes, very sorry about that. > > Has anyone succesfully used multiple PerlTransHandlers? > Is there anyway to "localize" (i.e. ) them so that they are > not always invoked? you might look toward Apache::AuthenCache to see how it handles the situation - authen handlers present a problem similar to trans handlers in the respect you are talking about. again, sorry for the bad info you've found. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Singleton
Hmmm after playing around with Apache::Singleton I am having a hard time understanding exactly how you use it. I failed to find even one complete example of it's use, just bits and pieces, and I'm afraid I don't understand how it all fits together. I read the Class::Singleton manpage and that didnt' help me either. Anyone have an example lying around or a link to one? -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Singleton
Here is the code that I cant' get working, maybe it is easier to just
correct what I have so far...
package Test::One;
use strict;
use Apache::Constants qw(:common);
use Apache::Singleton::Request;
use base qw(Apache::Singleton::Request);
use vars qw($r);
my $var1 = "test";
sub handler {
$r = shift;
print_header();
init();
return OK;
}
sub print_header{
$r->send_http_header('text/html');
}
sub init{
&testing::test;
}
package testing;
sub test {
my $test = Test::One->instance();
print $test->{var1};
}
1;
- Original Message -
From: "Chris Ochs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 16, 2003 1:22 PM
Subject: Apache::Singleton
>
>
> Hmmm after playing around with Apache::Singleton I am having a hard time
> understanding exactly how you use it. I failed to find even one complete
> example of it's use, just bits and pieces, and I'm afraid I don't
> understand
> how it all fits together. I read the Class::Singleton manpage and that
> didnt' help me either. Anyone have an example lying around or a link to
> one?
>
>
> --
> Reporting bugs: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
>
>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Request->instance(undef)
Dave Rolsky <[EMAIL PROTECTED]> writes:
> If you call Apache::Request->instance with an undefined value, it dies
> when it tries to call pnotes() on that argument.
>
> It seems to me that it should simply return a false value if given
> undef. This can happen if you have a piece of code like this:
>
> my $r = Apache::Request->instance(Apache->request);
>
> which may be called during server startup or during a request.
Would something like this be ok?
sub instance {
my ($class, $r) = @_;
return undef unless defined $r;
if (my $apreq = $r->pnotes('apreq')) {
return $apreq;
}
my $new_req = $class->new($r, @_);
$r->pnotes('apreq', $new_req);
return $new_req;
}
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems with Multiple PerlTransHandlers
Geoffrey Young wrote: Patrick LeBoutillier wrote: Hi all, I'm having some problems when I have with multiple PerlTransHandlers defined. What is happening is even if one handler returns OK, the other ones are still invoked. yes, this is a known issue. it's fixed in 2.0 but the behavior in 1.3 isn't likely to change. If it's not documented, then it should be. Geoff, can you add some docco to guide/config.pod? I'm not sure we have any other suitable place for this. May be guide/troubleshooting.pod is more suitable? __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Proxy Directive and PerlSetOutputFilter
Hi Stas, Yes indeed, SetOutputFilter bladibla works. The 'bladibla' output filter consists of a sed command (using mod_ext_filter). The Apache::bladibla filter is based on the modperl-2.0 documentation of the Obfuscation filter, where the substitution of the carriage return (in the obfuscation filter) is replaced by the substitution as defined earlier via sed in the bladibla filter. As I said before: Apache::bladibla works just fine as long as it's not defined between directives. Just wondering: the scope of PerlSetOutputFilter is [Dir]. could that be a/the reason why it isn't working in a proxied environment? But if this is the answer, is there an alternative solution? Sincerely, Erick -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Install as DSO problems
Hi, I am running Solaris 9, perl 5.6.1, apache 1.3.22. I am trying to install mod_perl as a DSO My steps are: perl Makefile.PL USE_APXS=1 WITH_APXS=/path/to/bin/apxs EVERYTHING=1 ourput is: Will configure via APXS (apxs=/usr/apache/bin/apxs) PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'other' Configuring mod_perl for building via APXS + Creating a local mod_perl source tree + Setting up mod_perl build environment (Makefile) + id: mod_perl/1.29 + id: Perl/v5.6.1 (solaris) [perl] Now please type 'make' to build libperl.so Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..failed Can't locate LWP/UserAgent.pm in @INC (@INC contains: ./lib /usr/perl5/5.6.1/lib/sun4-solaris-64int /usr/perl5/5.6.1/lib /usr/perl5/site_perl/5.6.1/sun4-solaris-64int /usr/perl5/site_perl/5.6.1 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int /usr/perl5/vendor_perl/5.6.1 /usr/perl5/vendor_perl .) at Makefile.PL line 1157. The libwww-perl library is needed to run the test suite. Installation of this library is recommended, but not required. Checking for HTML::HeadParserfailed Can't locate HTML/HeadParser.pm in @INC (@INC contains: ./lib /usr/perl5/5.6.1/lib/sun4-solaris-64int /usr/perl5/5.6.1/lib /usr/perl5/site_perl/5.6.1/sun4-solaris-64int /usr/perl5/site_perl/5.6.1 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int /usr/perl5/vendor_perl/5.6.1 /usr/perl5/vendor_perl .) at Makefile.PL line 1175. The HTML-Parser package is needed (by libwww-perl) to run the test suite. Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl Then make and I get: (cd ./apaci && PERL5LIB=/export/home/kevenj/mod_perl-1.29/lib: make) cc -KPIC -xO3 -xdepend -I/usr/perl5/5.6.1/lib/sun4-solaris-64int/CORE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL_VERSION=\"1.29\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.29\" -I/usr/apache/include -DMOD_PERL -DSOLARIS2=290 -DMOD_PERL -DEAPI -DUSE_EXPAT -I../lib/expat-lite -xO3 -xarch=v8 -xspace -W0,-Lt -Xa -xildoff -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c mod_perl.c && mv mod_perl.o mod_perl.lo cc: unrecognized option `-KPIC' cc: unrecognized option `-Xa' cc: language ildoff not recognized cc: mod_perl.c: linker input file unused because linking not done mv: cannot access mod_perl.o *** Error code 2 make: Fatal error: Command failed for target `mod_perl.lo' Current working directory /export/home/kevenj/mod_perl-1.29/apaci *** Error code 1 make: Fatal error: Command failed for target `apxs_libperl' Don't have cc and am using gcc 3.3.2. I linked /usr/local/bin/cc to my gcc binary and i am still getting the above error. Thanks for the help in advance!! Keven E. Jones, -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Proxy Directive and PerlSetOutputFilter
Erick Staal wrote: Hi Stas, Yes indeed, SetOutputFilter bladibla works. The 'bladibla' output filter consists of a sed command (using mod_ext_filter). The Apache::bladibla filter is based on the modperl-2.0 documentation of the Obfuscation filter, where the substitution of the carriage return (in the obfuscation filter) is replaced by the substitution as defined earlier via sed in the bladibla filter. As I said before: Apache::bladibla works just fine as long as it's not defined between directives. Just wondering: the scope of PerlSetOutputFilter is [Dir]. could that be a/the reason why it isn't working in a proxied environment? But if this is the answer, is there an alternative solution? MyApache::FilterObfuscate is a request filter. What's inside bladibla, how did you configured it? I don't seem to be able to include any filters from , e.g.: Order Deny,Allow Deny from 10.0.0.1 Allow from all SetOutputFilter DEFLATE SetOutputFilter INCLUDES #Options Indexes FollowSymLinks IncludesNoExec runs none of these filters. According to the docs: http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxy http://example.com/foo/*> SetOutputFilter INCLUDES should work. Did I miss something? Do you have any other relevant config parts? I can see that PerlOutputFilterHandler's dir_merge is run, but it never gets a chance to be inserted, I suppose because mod_proxy doesn't merge it with the current requests's config. It looks like mod_include is [Dir] too: http://httpd.apache.org/docs-2.0/mod/mod_include.html#enabling __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Proxy Directive and PerlSetOutputFilter
Stas Bekman wrote: I don't seem to be able to include any filters from , e.g.: Now I recall that Chris Pringle was running the filter without any problems. http://marc.theaimsgroup.com/?l=apache-modperl&m=107097076003389&w=2 But I fail to reproduce his setup. I have the data from the remote server, but no filters get applied (including non-modperl ones). Digging in httpd-2.0 config parser code is a nightmare. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Request->instance(undef)
On Tue, 16 Dec 2003, Joe Schaefer wrote:
> Dave Rolsky <[EMAIL PROTECTED]> writes:
>
> > If you call Apache::Request->instance with an undefined value, it dies
> > when it tries to call pnotes() on that argument.
> >
> > It seems to me that it should simply return a false value if given
> > undef. This can happen if you have a piece of code like this:
> >
> > my $r = Apache::Request->instance(Apache->request);
> >
> > which may be called during server startup or during a request.
>
> Would something like this be ok?
>
> sub instance {
> my ($class, $r) = @_;
> return undef unless defined $r;
Returning undef is kind of annoying, since it's true in list context. A
bare return is better, IMHO.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
> although nothing is reported in the error log, and the
> status in the access log is reported as 200. The problem
> arises from returning '200' from Apache::Hello; changing
>return 200;
> to
>return Apache::OK;
> fixes things.
>
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
>
Thanks for starting this thread Randy & figuring out what the
problem was. I have been swamped this past month, and have been
unable to look into this much, but as I understand it, using the
standard Apache constants is a fix here.
Having looked into this some already, it seems that the Apache handler
model in mod_perl has changed some with respect to the return codes
that a handler provides. It seemed that early in mod_perl use,
the return codes would be the literal status codes, like 500 for
server error, 302 for redirect and 200 for success. This is
then very different in mod_perl 2, and hopefully I can implement
this is some rational way so that Apache::ASP can still do something
correct with $Response->{Status} across mod_perl 1 + 2.
Thanks again, and I expect to have this problem resolved in the
next release of Apache::ASP, release date TBD. Unfortunately, this
"fix" seems rather involved, so I am not sure when this release date
will be.
Regards,
Josh
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
> It seemed that early in mod_perl use,
> the return codes would be the literal status codes, like 500 for
> server error, 302 for redirect and 200 for success. This is
> then very different in mod_perl 2, and hopefully I can implement
> this is some rational way so that Apache::ASP can still do something
> correct with $Response->{Status} across mod_perl 1 + 2.
302, 500, and all the other HTTP_* error codes still behave the same way.
what is different is that HTTP_OK (200) is no longer treated as OK (0).
other values that were altered to read as OK were returns < 100 and > 600,
but those probably don't matter. 200 is probably the only value you need to
worry about intercepting.
the bottom line is that request-time handlers need to return OK, DECLINED,
or DONE. all other responses (including 200) are treated as "errors" by
apache. this behavior, while new to mod_perl, is exactly the same as apache
itself, in both 1.3 and 2.0 - the change is that where mod_perl used to
second guess a handler's intent (by changing odd return codes to OK) it no
longer does so.
HTH
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
