Re: Problem with mod_perl and subroutines in multiple files.
Benjamin Grabkowitz wrote: I am a new Perl developer and just found out about the great benefits of mod_perl. I see that you try to work with mod_perl 2.0. So here is a bit of advice: mod_perl 2.0 (1.99_0x) while getting better every day, still has quite a few bugs, so you may want to start with the stable mod_perl 1.0 (1.27) instead and then move on to 2.0 when the time comes. If you do want to stick with mp2, (and we do want people to start using it to expose the bugs as early as possible), please make sure to use the latest cvs version, since what you use is a way too old and lots of bugs were fixed since 1.99_05. See: http://perl.apache.org/download/source.html#mod_perl_2_0 Finally regarding your original question, you probably need to read this: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs and may be spend some time around http://perl.apache.org/docs/1.0/guide/ for your own good ;) I had a Perl cgi script that ran fine. It consisted of 1 main.pl file and multiple subroutines that each had their own file in a directory called libs (it is in the same directory as main.pl). When I got mod_perl properly configured (or to what I thought was properly configured), I got strange errors like: ModPerl::PerlRun: Not a CODE reference at /var/www/cgi-bin/main.pl line 31. __ 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: [mp2] apache/mod_perl starup failure using cvs 09
[...]
why does Mason needs $r at the server startup? There is no
request object at
the server startup, so it's only fair that mp reports the error.
[...]
Good point. However, I seemed to have given you the code of
mason's ApacheHandler out of context; the snip above is from the
'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler->new (
args_method => "CGI",
comp_root => "/srv/www/htdocs",
data_dir=> "/srv/www/mason",
error_mode => 'output',
);
In this trivial case it doesn't seem worthwhile to go to all
that trouble, but, as in my production server, when working
with a lot of (possible dynamic) vhosts, it works well.
If the Apache->request (or a request passed as the last -
odd - parameter to new) is defined, some further processing
occurs; but at startup, the request is neither expected to
be there nor needed.
I guess (looking at my result matrix) that some change was made
to mod_perl to prohibit even querying the presence of
Apache->request at startup. So now I (and other mason folks)
must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
I see what you mean. In mp1 you relied on Apache->request's not being defined
as a side-effect to test whether you are inside request or not.
I will explain why I've chosen to croak, rather than return 'undef'.
In mp1 Apache->request was either undef (outside of request) or $r (during the
request). You couldn't control that. In mp2 in order to optimize things,
keeping the global request around is optional. So if you don't need it you get
some speed improvement.
So if the user has the global request setting off and Apache->request returns
undef, he may think that he is not inside the request phases (precisely what
mason does), which is wrong.
Therefore if you still wish to rely on this (which is no longer always valid
under mp2), you can do:
eval { $r = Apache->request}
to trap the croak.
may be you should use something else as a predicate to calling
Apache->request. For example you could use:
ModPerl::Util::current_callback() to figure out where you are. Though it'll
incur a checking of several options. So perhaps we need a new method or may be
not. Ideas are welcome.
Philippe has agreed with my reasoning when I've suggested the change and
nobody else has objected (or had any opinion at all), so it went in. Since
nothing is cast is stone (yet) on the mp2 API, you may suggest your
explanation why it should behave differently if you think that my idea is wrong.
__
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: [mp2] apache/mod_perl starup failure using cvs 09
Hi Stas -
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 6:18 PM
> To: Beau E. Cox
> Cc: Modperl
> Subject: Re: [mp2] apache/mod_perl starup failure using cvs 09
>
>
> Beau E. Cox wrote:
> > -8<-- Start Bug Report 8<--
> > 1. Problem Description:
> >
> > Sorry - is this mason's problem?
> >
> > Apache does not start using latest mod_perl2 (cvs) when
> > using a mason startup script.
> >
> > Failure matrix:
> >
> > mod_perl version mason version using startup.pl using
> simple-mason.pl
> > OK?
> >
> --
> >
> > 08-source 1.16 yes yes
> > OK
> > 08-source 1.19 yes yes
> > OK
> > 09-cvs 1.19 yes yes
> > FAIL
> > 09-cvs 1.16 yes yes
> > FAIL
> > 09-cvs 1.19 no-in httpd no mason
> > OK
> > 09-cvs 1.19 no-in httpd no-in httpd
> > OK
> >
> > Apache startup console output:
> >
> > [Tue Mar 04 16:45:09 2003] [error] Global $r object is not
> available. Set:
> > PerlOptions +GlobalRequest
> > in httpd.conf at
> /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
> > line 573.
> > Compilation failed in require at (eval 3) line 1.
>
> [...]
>
> > HTML::Mason::ApacheHandler revelant lines:
> >
> > my $allowed_params = $class->allowed_params(%defaults, %params);
> >
> > 573: if ( exists $allowed_params->{comp_root} and
> > my $req = $r || Apache->request ) # DocumentRoot is only
> available
>
> why does Mason needs $r at the server startup? There is no
> request object at
> the server startup, so it's only fair that mp reports the error.
>
> __
> 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
>
>
Good point. However, I seemed to have given you the code of
mason's ApacheHandler out of context; the snip above is from the
'new' method which I use in setting up the mason handler routine:
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler->new (
args_method => "CGI",
comp_root => "/srv/www/htdocs",
data_dir=> "/srv/www/mason",
error_mode => 'output',
);
In this trivial case it doesn't seem worthwhile to go to all
that trouble, but, as in my production server, when working
with a lot of (possible dynamic) vhosts, it works well.
If the Apache->request (or a request passed as the last -
odd - parameter to new) is defined, some further processing
occurs; but at startup, the request is neither expected to
be there nor needed.
I guess (looking at my result matrix) that some change was made
to mod_perl to prohibit even querying the presence of
Apache->request at startup. So now I (and other mason folks)
must find another way to instantiate handlers.
Would you have and suggestions from the mod_perl perspective?
I will take this query over to mason if you feel that is where
it belongs - but I'll need some further insight into the mod_perl
changes.
Aloha => Beau;
Problem with mod_perl and subroutines in multiple files.
I am a new Perl developer and just found out about the great benefits of mod_perl. I had a Perl cgi script that ran fine. It consisted of 1 main.pl file and multiple subroutines that each had their own file in a directory called libs (it is in the same directory as main.pl). When I got mod_perl properly configured (or to what I thought was properly configured), I got strange errors like: ModPerl::PerlRun: Not a CODE reference at /var/www/cgi-bin/main.pl line 31. Line 31 turned out to be a function call. If I commented out line 31 it would give me the same error for the next line with a subroutine call. The strange thing is that the script would run for like 3 or 4 times after each apache restart. Now I kind of (I emphasize kind of) worked out a solution. If I take all my subroutine files and merge them to the end of main.pl. Everything runs fine, not only fine...but blazingly quick. Anyone have any ideas? My box info: RedHat 8.0 (pretty much a stock system...other than the RH updates) httpd-2.0.40-15 (apache) perl-5.8.0-55 mod_perl-1.99_05-3 I added the following to httpd.conf to get mod_perl working...please school me if I am totally out of line. BEGIN ADDITION TO HTTPD.CONF* PerlModule Apache2 PerlModule DBI SetHandler perl-script PerlHandler ModPerl::PerlRun PerlSendHeader On PerlOptions +ParseHeaders Options ExecCGI FollowSymLinks Includes END** Thank you for your time, -Ben Grabkowitz
SetConsoleMode failed, LastError=|6| at C:/Perl/site/lib/Term/ReadKey.pm line 268, line 6.
I just downloaded the all-in-one and, as per Randy's instructions, abandoned my current installations of Apache2 and perl5.8 by uninstalling them. I just typed in the perl configure.pl command and I receive: SetConsoleMode failed, LastError=|6| at C:/Perl/site/lib/Term/ReadKey.pm line 26 8, line 6. cpan> Should I be concerned? Actually, here are all the error messages at the end of this email message. Apparently most of them are warning messages. Also, what is httpd-win.conf for? Which one is being used, httpd.conf or httpd-win.conf? Thanks, Siegfried 31. installhtml: C:/Perl/site/lib/Tk/Pod/Search_db.pm: cannot resolve L i n paragraph 52. installhtml: C:/Perl/site/lib/Tk/Pod/Text.pm: cannot resolve L in p aragraph 71. installhtml: C:/Perl/site/lib/Tk/Pod/Text.pm: cannot resolve L in paragraph 71. installhtml: no title for C:/Perl/site/lib/Tk/Text/Tag.pm. installhtml: C:/Perl/site/lib/Tk/DropSite.pod: unexpected =item directive in par agraph 10. ignoring. installhtml: C:/Perl/site/lib/Tk/Entry.pod: unterminated list at =head in paragr aph 147. ignoring. installhtml: C:/Perl/site/lib/Tk/Listbox.pod: unterminated list at =head in para graph 196. ignoring. installhtml: C:/Perl/site/lib/Tk/Pod_usage.pod: cannot resolve L in parag raph 30. installhtml: C:/Perl/site/lib/Tk/Pod_usage.pod: cannot resolve L in par agraph 30. installhtml: C:/Perl/site/lib/Tk/Pod_usage.pod: cannot resolve L in pa ragraph 30. installhtml: C:/Perl/site/lib/Tk/Pod_usage.pod: cannot resolve L in pa ragraph 30. installhtml: no title for C:/Perl/site/lib/Tk/Adjuster.pm. installhtml: no title for C:/Perl/site/lib/Tk/After.pm. installhtml: no title for C:/Perl/site/lib/Tk/Animation.pm. installhtml: no title for C:/Perl/site/lib/Tk/Balloon.pm. installhtml: no title for C:/Perl/site/lib/Tk/Bitmap.pm. installhtml: no title for C:/Perl/site/lib/Tk/BrowseEntry.pm. installhtml: no title for C:/Perl/site/lib/Tk/Button.pm. installhtml: no title for C:/Perl/site/lib/Tk/Canvas.pm. installhtml: no title for C:/Perl/site/lib/Tk/Checkbutton.pm. installhtml: no title for C:/Perl/site/lib/Tk/Clipboard.pm. installhtml: no title for C:/Perl/site/lib/Tk/ColorEditor.pm. installhtml: no title for C:/Perl/site/lib/Tk/Compound.pm. installhtml: no title for C:/Perl/site/lib/Tk/Config.pm. installhtml: no title for C:/Perl/site/lib/Tk/Configure.pm. installhtml: no title for C:/Perl/site/lib/Tk/Derived.pm. installhtml: no title for C:/Perl/site/lib/Tk/Dialog.pm. installhtml: no title for C:/Perl/site/lib/Tk/DialogBox.pm. installhtml: no title for C:/Perl/site/lib/Tk/Dirlist.pm. installhtml: no title for C:/Perl/site/lib/Tk/DirTree.pm. installhtml: no title for C:/Perl/site/lib/Tk/DragDrop.pm. installhtml: no title for C:/Perl/site/lib/Tk/DropSite.pm. installhtml: no title for C:/Perl/site/lib/Tk/English.pm. installhtml: no title for C:/Perl/site/lib/Tk/Entry.pm. installhtml: no title for C:/Perl/site/lib/Tk/ErrorDialog.pm. installhtml: no title for C:/Perl/site/lib/Tk/Event.pm. installhtml: no title for C:/Perl/site/lib/Tk/FBox.pm. installhtml: no title for C:/Perl/site/lib/Tk/FileSelect.pm. installhtml: no title for C:/Perl/site/lib/Tk/FloatEntry.pm. installhtml: no title for C:/Perl/site/lib/Tk/Font.pm. installhtml: no title for C:/Perl/site/lib/Tk/Frame.pm. installhtml: no title for C:/Perl/site/lib/Tk/HList.pm. installhtml: no title for C:/Perl/site/lib/Tk/IconList.pm. installhtml: no title for C:/Perl/site/lib/Tk/Image.pm. installhtml: no title for C:/Perl/site/lib/Tk/install.pm. installhtml: no title for C:/Perl/site/lib/Tk/IO.pm. installhtml: no title for C:/Perl/site/lib/Tk/ItemStyle.pm. installhtml: no title for C:/Perl/site/lib/Tk/Label.pm. installhtml: no title for C:/Perl/site/lib/Tk/LabEntry.pm. installhtml: no title for C:/Perl/site/lib/Tk/LabFrame.pm. installhtml: no title for C:/Perl/site/lib/Tk/LabRadio.pm. installhtml: no title for C:/Perl/site/lib/Tk/Listbox.pm. installhtml: no title for C:/Perl/site/lib/Tk/MainWindow.pm. installhtml: no title for C:/Perl/site/lib/Tk/MakeDepend.pm. installhtml: no title for C:/Perl/site/lib/Tk/Menu.pm. installhtml: no title for C:/Perl/site/lib/Tk/Menubar.pm. installhtml: no title for C:/Perl/site/lib/Tk/Menubutton.pm. installhtml: no title for C:/Perl/site/lib/Tk/Message.pm. installhtml: no title for C:/Perl/site/lib/Tk/MMtry.pm. installhtml: no title for C:/Perl/site/lib/Tk/MMutil.pm. installhtml: no title for C:/Perl/site/lib/Tk/NBFrame.pm. installhtml: no title for C:/Perl/site/lib/Tk/NoteBook.pm. installhtml: no title for C:/Perl/site/lib/Tk/Optionmenu.pm. installhtml: no title for C:/Perl/site/lib/Tk/Photo.pm. installhtml: no title for C:/Perl/site/lib/Tk/Pixmap.pm. installhtml: C:/Perl/site/lib/Tk/Pod.pm: cannot resolve L in paragr aph 31. installhtml: no title for C:/Perl/site/lib/Tk/Pretty.pm. installhtml: no title for C:/Perl/site/lib/Tk/Radiobutton.pm. installhtml: no title for C:/Perl/site/lib/Tk/Region.pm. installhtml: C:/Perl/site/lib/Tk/Reindex.pm: unexpected =item directive in pa
[ANNOUNCE] Apache Hello World Benchmarks v1.02
Hey, I have published the latest Hello World benchmarks, available at: http://chamas.com/bench/ Just updated are: - PHP 4.3.0 built with domxml extensions for XSLT tests - HTML::Embperl 1.3.6 - HTML::Mason 1.19 The PHP XSLT test are new, and the performance is similar is Embperl2 and it doesn't seem to have a built in XSLT caching layer like AxKit, Apache::ASP & Resin. I thought it was interesting that Embperl 2 (barely) beat out PHP 4.3.0 on XSLT in both the XSLT Hello & XSLT Big tests. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
mod_perl Cookbook example
Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? Regards, Ashish _ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus
Re: [mp2] apache/mod_perl starup failure using cvs 09
Beau E. Cox wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[...]
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class->allowed_params(%defaults, %params);
573: if ( exists $allowed_params->{comp_root} and
my $req = $r || Apache->request ) # DocumentRoot is only available
why does Mason needs $r at the server startup? There is no request object at
the server startup, so it's only fair that mp reports the error.
__
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
[mp2] apache/mod_perl starup failure using cvs 09
-8<-- Start Bug Report 8<--
1. Problem Description:
Sorry - is this mason's problem?
Apache does not start using latest mod_perl2 (cvs) when
using a mason startup script.
Failure matrix:
mod_perl version mason version using startup.pl using simple-mason.pl
OK?
--
08-source 1.16 yes yes
OK
08-source 1.19 yes yes
OK
09-cvs 1.19 yes yes
FAIL
09-cvs 1.16 yes yes
FAIL
09-cvs 1.19 no-in httpd no mason
OK
09-cvs 1.19 no-in httpd no-in httpd
OK
Apache startup console output:
[Tue Mar 04 16:45:09 2003] [error] Global $r object is not available. Set:
PerlOptions +GlobalRequest
in httpd.conf at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm
line 573.
Compilation failed in require at (eval 3) line 1.
[Tue Mar 04 16:45:09 2003] [error] Can't load Perl file:
/srv/www/conf/simple-mason.pl for server TOMOKO.beaucox.com:0, exiting...
Apache error.log - no entries
Apache rcapache.log - Syntax OK
Apache access.log - no entries
mod_perl/mason (1.19) relevant entries in httpd.conf:
LoadModule perl_module /srv/www/modules/mod_perl.so
PerlRequire "/srv/www/conf/startup.pl"
Alias /perl/ /srv/www/perl/
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
PerlRequire "/srv/www/conf/simple-mason.pl"
SetHandler perl-script
PerlHandler MyMason::MyApp
/srv/www/conf/startup.pl
use Apache2 ();
use lib qw(/srv/www/perl);
use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Session ();
use CGI::Cookie ();
use APR::Table ();
use ModPerl::Registry ();
use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';
1;
/srv/www/conf/simple-mason.pl
#!/usr/bin/perl
#
# A basic, functional Mason handler.pl.
#
package MyMason::MyApp;
#
# Setup for mod_perl 2
use Apache2 ();
use Apache::compat ();
# Preload CGI since we are using it for mod_perl 2
use CGI ();
# Bring in Mason with Apache support.
use HTML::Mason::ApacheHandler;
use strict;
#
# List of modules that you want to use within components.
{
package HTML::Mason::Commands;
use Data::Dumper;
}
# Create ApacheHandler object at startup.
my $ah =
HTML::Mason::ApacheHandler->new (
args_method => "CGI",
comp_root => "/srv/www/htdocs",
data_dir=> "/srv/www/mason",
error_mode => 'output',
);
#
sub handler
{
my ($r) = @_;
my $status = $ah->handle_request($r);
return $status;
}
#
1;
HTML::Mason::ApacheHandler revelant lines:
my $allowed_params = $class->allowed_params(%defaults, %params);
573: if ( exists $allowed_params->{comp_root} and
my $req = $r || Apache->request ) # DocumentRoot is only available
inside requests
{
$defaults{comp_root} = $req->document_root;
}
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX=> /usr/local/apache2
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /usr/local/apache2/sbin/httpd -V
Server version: Apache/2.0.44
Server built: Mar 4 2003 14:35:52
Server's Module Magic Number: 20020903:0
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local/apache2"
-D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/httpd/mime.types"
-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.19, archname=i586-linux-thread-multi
uname='linux amdsim5 2.4.19 #1 wed mar 27 13:57:05 utc 2002 i686 unknown
'
config_args='-ds -e -Dprefix=/usr -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_g
dbm -Duseshrplib=true'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags
='-D
RE: [mp2] Latest mod_perl funny test results
Hi Stas - > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 04, 2003 4:01 PM > To: Beau E. Cox > Cc: Modperl > Subject: Re: [mp2] Latest mod_perl funny test results > > > Beau E. Cox wrote: > > Hi - > > > > I just upgraded to Apache 2.0.44 (source) and mod_perl-1.99-09-dev > > (CVS source) on my SuSE 8.1 test server. All test scripts completed > > OK. I am omitting the details of my configuration - will supply them > > if anyone thinks this problem is related to them. > > > > As I have with prior installations, I am tip-toeing through the > > tests until my server is completely up to date (+mason, +mod_ssl, > > +lots of vhosts, etc.). > > > > To start, I set my httpd.conf as per the mod_perl docs: > > > > LoadModule perl_module /srv/www/modules/mod_perl.so > > PerlRequire "/srv/www/conf/startup.pl" > > > > Alias /perl/ /srv/www/perl/ > > > > SetHandler perl-script > > PerlResponseHandler ModPerl::Registry > > PerlOptions +ParseHeaders > > Options +ExecCGI > > > > > > And wrote the test script in /srv/www/perl/rocks.html (with > > the proper permissions/ownership): > > > > #!/usr/bin/perl > > print "Content-type: text/html\n\n"; > > print "mod_perl 2.0 rocks!\n"; > > > > Browsing to localhost/perl/rocks.html gives: > > > > Content-type: text/html > > > > mod_perl 2.0 rocks! > > > > (with the second line emboldened to h3). The > > view->source shows: > > > > Content-type: text/html > > > > mod_perl 2.0 rocks! > > > > Question: why isn't my 'Content-type' line output as a HTTP header? > > Good catch, Beau. I broke the header parsing in one of the recent commits. > Apparently relying on content_type not being set before the > response handler > was a bad bet. the default mime handler probably sets it since > the file is > called .html, whereas all our registry tests are .pl, which the > mime handler > doesn't know what to do with and therefore sets no content_type() do they > weren't catching the problem. > > I'll fix that in a few days, since what I was trying to do is to > solve some > other more complicated problems. So it requires a good thinking > how to solve > them in a different way. So please bear with me. I want to finish > first the > update of the filters tutorial, and then will be back to fixing things. > > __ > 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 > > Thanks. Hey, not important - so make it low priority unless someone else needs it. You're right, changing the name to 'rocks.pl' produces correct output. Aloha => Beau; PS: Got a hum-dinger on the way!!!
Re: [mp2] Latest mod_perl funny test results
Beau E. Cox wrote: Hi - I just upgraded to Apache 2.0.44 (source) and mod_perl-1.99-09-dev (CVS source) on my SuSE 8.1 test server. All test scripts completed OK. I am omitting the details of my configuration - will supply them if anyone thinks this problem is related to them. As I have with prior installations, I am tip-toeing through the tests until my server is completely up to date (+mason, +mod_ssl, +lots of vhosts, etc.). To start, I set my httpd.conf as per the mod_perl docs: LoadModule perl_module /srv/www/modules/mod_perl.so PerlRequire "/srv/www/conf/startup.pl" Alias /perl/ /srv/www/perl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI And wrote the test script in /srv/www/perl/rocks.html (with the proper permissions/ownership): #!/usr/bin/perl print "Content-type: text/html\n\n"; print "mod_perl 2.0 rocks!\n"; Browsing to localhost/perl/rocks.html gives: Content-type: text/html mod_perl 2.0 rocks! (with the second line emboldened to h3). The view->source shows: Content-type: text/html mod_perl 2.0 rocks! Question: why isn't my 'Content-type' line output as a HTTP header? Good catch, Beau. I broke the header parsing in one of the recent commits. Apparently relying on content_type not being set before the response handler was a bad bet. the default mime handler probably sets it since the file is called .html, whereas all our registry tests are .pl, which the mime handler doesn't know what to do with and therefore sets no content_type() do they weren't catching the problem. I'll fix that in a few days, since what I was trying to do is to solve some other more complicated problems. So it requires a good thinking how to solve them in a different way. So please bear with me. I want to finish first the update of the filters tutorial, and then will be back to fixing things. __ 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: SubRequest weirdness
[moving this back to the users list]
Jon Salz wrote:
Sorry, I'm not sure if I've found a mod_perl bug or if I'm just doing
something wrong. Any idea why the following behavior happens?:
test1.pl is
use Apache::SubRequest;
Apache->request->lookup_uri("test2.pl")->run;
test2.pl is
print "Content-type: text/html\nSet-Cookie: foo=bar\n\nHello world!";
test2.pl works fine by itself, but when I run test1.pl, the server output
is
HTTP/1.1 200 OK
Date: Mon, 03 Mar 2003 06:48:59 GMT
Server: Apache/2.0.44 (Unix) mod_perl/1.99_08 Perl/v5.8.0 DAV/2
Connection: close
Content-Type: text/plain; charset=ISO-8859-1
Hello world!
i.e., the Content-Type and Set-Cookie in test2.pl get ignored but the
content goes through just fine. Any idea what I'm doing wrong?
This doesn't seem to work with mp1 as well. So I doubt it's a bug in mp2.
in mp1 test.pl doesn't send headers at all:
telnet localhost 8000
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
GET /perl/callsubreq.pl HTTP/1.0
Hello world!Connection closed by foreign host.
The eagle book says that the headers should be forwarded, but they aren't.
__
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
[mp2] Latest mod_perl funny test results
Hi - I just upgraded to Apache 2.0.44 (source) and mod_perl-1.99-09-dev (CVS source) on my SuSE 8.1 test server. All test scripts completed OK. I am omitting the details of my configuration - will supply them if anyone thinks this problem is related to them. As I have with prior installations, I am tip-toeing through the tests until my server is completely up to date (+mason, +mod_ssl, +lots of vhosts, etc.). To start, I set my httpd.conf as per the mod_perl docs: LoadModule perl_module /srv/www/modules/mod_perl.so PerlRequire "/srv/www/conf/startup.pl" Alias /perl/ /srv/www/perl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI And wrote the test script in /srv/www/perl/rocks.html (with the proper permissions/ownership): #!/usr/bin/perl print "Content-type: text/html\n\n"; print "mod_perl 2.0 rocks!\n"; Browsing to localhost/perl/rocks.html gives: Content-type: text/html mod_perl 2.0 rocks! (with the second line emboldened to h3). The view->source shows: Content-type: text/html mod_perl 2.0 rocks! Question: why isn't my 'Content-type' line output as a HTTP header? Aloha => Beau;
Fwd: Source Code Oraginzation
from Stas advice, I'm forwarding this here, sans the crosspostings.
Thanks for the help.
-- Forwarded Message --
Subject: Source Code Oraginzation
Date: Tue, 4 Mar 2003 15:58:38 +
From: "Philip M. Gollucci" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
I need good reasons why to do the following
/cgi-bin
*.pm
*.plex files (PerlEX)
*.cgi files
_no subdirectories_
VS
/cgi-bin
*.plex
*.cgi
packages/AMS/
some *.pm files
more directories with other *.pm files
OOP approach
Not quite sure where this one goes, but I know everyone here are more then
qualified to answer this.
I recently took shit for doing this, and I know at the _very_ least this
is correctly from a security standpoint as now _ALL_ our code is out of
web space. I need other good reasons as well, other then for organization.
Also, documenting where a function is located ?
I like the namespace prefix
package HomeScreens;
@EXPORT = (
hs_*
)
sub hs_* {
}
sub not_exported_func { }
VS
Export nothing
and use &HomeScreens::hs_*();
I'd like to hear agruments for and against.
END
-
- Philip M. Gollucci [EMAIL PROTECTED] 301.474.9294 301.646.3011 (cell)
Science, Discovery, & the Universe (UMCP)
Webmaster & Webship Teacher
URL: http://www.sdu.umd.edu
eJournalPress
Database/PERL Programmer & System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.net/Resume
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
--
END
--
Philip M. Gollucci [EMAIL PROTECTED] 301.474.9294 301.646.3011 (cell)
Science, Discovery, & the Universe (UMCP)
Webmaster & Webship Teacher
URL: http://www.sdu.umd.edu
eJournalPress
Database/PERL Programmer & System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.net/Resume
Re: Trouble with sysread in modperl
Liu, Hui (GXS) wrote:
There appears to be a bug with the read and sysread functions when being
used in a loop to read STDIN. We're using a loop to read from STDIN in
4k blocks, and the read or sysread appears to work great until the very
last read to pick up the final partial block. Here is the code:
$readSize = &min($bytesLeft, $blockReadSize);
$bufferLength = length($buffer);
$bytesRead = sysread(STDIN, $dataRead, $readSize);
&html("bytesRead=[$bytesRead . $bufferLength . $dataRead]") if ($debug);
if (!(defined $bytesRead)) {
$bytesRead = 0;
}
$buffer .= $dataRead;
In the last loop, the values that are returned in the debug statement
are: 674 . 3268 .
So sysread says that 674 bytes were read, however $dataRead is empty.
Both read and sysread exhibit the same behavior, returning the right
number of bytes to be read, but not populating the variable with the
actual data. This code works fine in versions of Perl other than Apache
modperl. Has anyone experienced this behavior and have any suggestions?
Could it be the buffering issue as described in the manpage?
perldoc -f sysread:
sysread FILEHANDLE,SCALAR,LENGTH,OFFSET
sysread FILEHANDLE,SCALAR,LENGTH
Attempts to read LENGTH characters of data into variable SCALAR
from the specified FILEHANDLE, using the system call read(2).
It bypasses buffered IO, so mixing this with other kinds of
reads, "print", "write", "seek", "tell", or "eof" can cause
confusion because stdio usually buffers data. Returns the num-
ber of characters actually read, 0 at end of file, or undef if
there was an error. SCALAR will be grown or shrunk so that the
last byte actually read is the last byte of the scalar after
the read.
[...]
can you try whether you get all the data, by reading via (even though
you have no control over chunks size)
__
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: Apache::DBI on mp2
Haroon Rafique wrote: On Today at 11:16am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> FWIW, we are discussing the internal DBI pooling mechanism at the SB> dbi-dev list and having already a sort-of-working prototype. So SB> hopefully there will be no need for Apache::DBI in the near future, as SB> DBI will be able to handle pooling internally. However it may take SB> some time, as the drivers will have to adjust to support the new SB> functionality. SB> SB> You can see the thread here: SB> http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB> SB> Some working examples are attached to this message: SB> http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB> Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. I've already tried it and it works ;) However DBI::Pool won't have a life on its own and will be integrated into DBI itself and its DBD drivers. SB> [..snip..] SB> SB> If you apply the following patch (will commit it soon) against the modperl-2.0 SB> source, you will be able to use connect_on_init unmodified, assuming that SB> Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB> you. SB> I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. __ 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: mod_perl books (Was: RE: Trouble with sysread in modperl)
Title: RE: mod_perl books (Was: RE: Trouble with sysread in modperl) Larry and Huili, Thank you very much for the information and all your help. I just ordered a book called "mod_perl Developer's Cookbook" by Geoffrey Young, et al. from Amazon.com. I hope we will go from there. Regards, Hui Liu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 04, 2003 3:40 PM To: Liu, Hui (GXS) Cc: mod_perl list Subject: Re: mod_perl books (Was: RE: Trouble with sysread in modperl) Hi Hui Liu You can start from http://perl.apache.org/docs/2.0/user/intro/start_fast.pdf instead of reading the very thick books. You can google to find out example codes as well. Gook Luck, Huili Liu Larry Leszczynski <[EMAIL PROTECTED] To: "Liu, Hui (GXS)" <[EMAIL PROTECTED]> > cc: mod_perl list <[EMAIL PROTECTED]> Subject: mod_perl books (Was: RE: Trouble with sysread in modperl) 03/04/2003 03:40 PM Please respond to Larry Leszczynski Hi Hui Liu - > Larry, > > Thank you. I wonder which Mod_perl cook book you are referring to and > where can we get them? I am very interested in details of recipe 3.8. > This is our first time to port our perl scripts to Apache (we are > using Apache:PerRun mode), and we are still learning. The best overall online resource is the mod_perl web site at: http://perl.apache.org/ Books related to mod_perl, including the "mod_perl Developer's Cookbook", are listed at: http://perl.apache.org/docs/offsite/books.html Larry Leszczynski [EMAIL PROTECTED]
Re: mod_perl books (Was: RE: Trouble with sysread in modperl)
Hi all, my name is Jordan and I've been monitoring this discussion group learning slowly how apache and mod_perl works. though I've rarely ever posted any questions or concerns regarding my configurations, I found that this discussion group has provided many answers to my multitude of questions. I just wanted to say thanks, you've all been a great help :-) ~jordan - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "mod_perl list" <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 3:39 PM Subject: Re: mod_perl books (Was: RE: Trouble with sysread in modperl) > > Hi Hui Liu > > You can start from > http://perl.apache.org/docs/2.0/user/intro/start_fast.pdf instead of > reading the very thick books. You can google to find out example codes as > well. > > Gook Luck, > > Huili Liu > > > > > > > Larry Leszczynski > <[EMAIL PROTECTED]To: "Liu, Hui (GXS)" <[EMAIL PROTECTED]> > >cc: mod_perl list <[EMAIL PROTECTED]> >Subject: mod_perl books (Was: RE: Trouble with sysread in modperl) > 03/04/2003 03:40 > PM > Please respond to > Larry Leszczynski > > > > > > > Hi Hui Liu - > > > Larry, > > > > Thank you. I wonder which Mod_perl cook book you are referring to and > > where can we get them? I am very interested in details of recipe 3.8. > > This is our first time to port our perl scripts to Apache (we are > > using Apache:PerRun mode), and we are still learning. > > The best overall online resource is the mod_perl web site at: >http://perl.apache.org/ > > Books related to mod_perl, including the "mod_perl Developer's Cookbook", > are listed at: >http://perl.apache.org/docs/offsite/books.html > > > > Larry Leszczynski > [EMAIL PROTECTED] > > > > > >
Re: mod_perl books (Was: RE: Trouble with sysread in modperl)
Hi Hui Liu You can start from http://perl.apache.org/docs/2.0/user/intro/start_fast.pdf instead of reading the very thick books. You can google to find out example codes as well. Gook Luck, Huili Liu Larry Leszczynski <[EMAIL PROTECTED]To: "Liu, Hui (GXS)" <[EMAIL PROTECTED]> >cc: mod_perl list <[EMAIL PROTECTED]> Subject: mod_perl books (Was: RE: Trouble with sysread in modperl) 03/04/2003 03:40 PM Please respond to Larry Leszczynski Hi Hui Liu - > Larry, > > Thank you. I wonder which Mod_perl cook book you are referring to and > where can we get them? I am very interested in details of recipe 3.8. > This is our first time to port our perl scripts to Apache (we are > using Apache:PerRun mode), and we are still learning. The best overall online resource is the mod_perl web site at: http://perl.apache.org/ Books related to mod_perl, including the "mod_perl Developer's Cookbook", are listed at: http://perl.apache.org/docs/offsite/books.html Larry Leszczynski [EMAIL PROTECTED]
mod_perl books (Was: RE: Trouble with sysread in modperl)
Hi Hui Liu - > Larry, > > Thank you. I wonder which Mod_perl cook book you are referring to and > where can we get them? I am very interested in details of recipe 3.8. > This is our first time to port our perl scripts to Apache (we are > using Apache:PerRun mode), and we are still learning. The best overall online resource is the mod_perl web site at: http://perl.apache.org/ Books related to mod_perl, including the "mod_perl Developer's Cookbook", are listed at: http://perl.apache.org/docs/offsite/books.html Larry Leszczynski [EMAIL PROTECTED]
RE: Trouble with sysread in modperl
Title: RE: Trouble with sysread in modperl
Larry,
Thank you. I wonder which Mod_perl cook book you are referring to and where can we get them? I am very interested in details of recipe 3.8. This is our first time to port our perl scripts to Apache (we are using Apache:PerRun mode), and we are still learning.
Thanks and Regards,
Hui Liu
-Original Message-
From: Larry Leszczynski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 3:16 PM
To: Liu, Hui (GXS)
Cc: mod_perl list
Subject: RE: Trouble with sysread in modperl
Hi Hui Liu -
> > Not sure about that error, but by any chance are you trying to read
> > POSTed data from the request? If so, all you need to do is:
> >
> > my $content;
> > $r->read($content, $r->header_in('Content-length'));
> >
> > (mod_perl cookbook recipe 3.6)
>
> Thanks for the suggestion. Does this mean if we have a 20MB file,
> this "read" will load the entire file into the memory?
Yes, at least up to the size limit defined by POST_MAX. But if you're
trying to read uploaded files, don't do it like that. Instead do it like
recipe 3.8 which shows how to get a filehandle to the uploaded file, e.g.
something like:
use Apache::Request;
sub handler {
my $r = Apache::Request->new(shift,
POST_MAX => 20 * 1024 * 1024,
DISABLE_UPLOADS => 0);
foreach my $upload ($r->upload) {
my $fh = $upload->fh;
...
}
}
Larry Leszczynski
[EMAIL PROTECTED]
RE: Trouble with sysread in modperl
Hi Hui Liu -
> > Not sure about that error, but by any chance are you trying to read
> > POSTed data from the request? If so, all you need to do is:
> >
> >my $content;
> >$r->read($content, $r->header_in('Content-length'));
> >
> > (mod_perl cookbook recipe 3.6)
>
> Thanks for the suggestion. Does this mean if we have a 20MB file,
> this "read" will load the entire file into the memory?
Yes, at least up to the size limit defined by POST_MAX. But if you're
trying to read uploaded files, don't do it like that. Instead do it like
recipe 3.8 which shows how to get a filehandle to the uploaded file, e.g.
something like:
use Apache::Request;
sub handler {
my $r = Apache::Request->new(shift,
POST_MAX => 20 * 1024 * 1024,
DISABLE_UPLOADS => 0);
foreach my $upload ($r->upload) {
my $fh = $upload->fh;
...
}
}
Larry Leszczynski
[EMAIL PROTECTED]
RE: Trouble with sysread in modperl
Title: RE: Trouble with sysread in modperl
Larry,
Thanks for the suggestion. Does this mean if we have a 20MB file, this "read" will load the entire file into the memory?
Regards,
Hui Liu
-Original Message-
From: Larry Leszczynski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 04, 2003 1:03 PM
To: Liu, Hui (GXS)
Cc: [EMAIL PROTECTED]
Subject: Re: Trouble with sysread in modperl
Hello -
> There appears to be a bug with the read and sysread functions when being
> used in a loop to read STDIN. We're using a loop to read from STDIN in 4k
> blocks, and the read or sysread appears to work great until the very last
> read to pick up the final partial block.
[snip]
Not sure about that error, but by any chance are you trying to read POSTed
data from the request? If so, all you need to do is:
my $content;
$r->read($content, $r->header_in('Content-length'));
(mod_perl cookbook recipe 3.6)
Larry Leszczynski
[EMAIL PROTECTED]
Re: Trouble with sysread in modperl
Hello -
> There appears to be a bug with the read and sysread functions when being
> used in a loop to read STDIN. We're using a loop to read from STDIN in 4k
> blocks, and the read or sysread appears to work great until the very last
> read to pick up the final partial block.
[snip]
Not sure about that error, but by any chance are you trying to read POSTed
data from the request? If so, all you need to do is:
my $content;
$r->read($content, $r->header_in('Content-length'));
(mod_perl cookbook recipe 3.6)
Larry Leszczynski
[EMAIL PROTECTED]
Re: PerlCleanupHandler called from default-handler
Tom Murphy wrote: I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: "..a C module has to specifically want this processing to occur-it is not called automatically." well, what we said is true, but you're reading it the wrong way :) basically, all of the Perl*Handler directives - from PerlPostReadRequestHandler to PerlCleanupHandler - can be thought of as parts of the request cycle. however, this is true for all but the PerlCleanupHandler, which really isn't part of the request cycle - mod_perl just makes it look that way. what's really happening is that mod_perl is hooking your Perl handler into the per-request cleanup that Apache offers all C modules (mod_perl included). so it _should_ be called for every request it is configured to run for (should being highly caveated - people have reported that _sometimes_ this doesn't really happen). understanding that is A Good Thing. however, it's not going to help you very much here :) How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. if the PerlLogHandler doesn't get called then you probably have a configuration problem. both of these can exist on their own, outside of a container. something like PerlLogHandler NC::LogHandler ... if that doesn't show your log handler running then you need to check your error log for errors and make sure your handler compiles under perl -cw or something - if the log handler errors out, you really can't see it unless you look. of course, all this assumes that you built with EVERYTHING=1 - check Apache::Status to make sure. another thing you can try if that doesn't work out is compiling a debugging mod_perl (PERL_DEBUG=1 and PERL_TRACE=1 when building) and set PerlSetEnv MOD_PERL_TRACE on and watch the verbose output. HTH --Geoff
PerlCleanupHandler called from default-handler
I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: "..a C module has to specifically want this processing to occur-it is not called automatically." How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. TIA, Tom Murphy
Trouble with sysread in modperl
Title: Trouble with sysread in modperl
There appears to be a bug with the read and sysread functions when being used in a loop to read STDIN. We're using a loop to read from STDIN in 4k blocks, and the read or sysread appears to work great until the very last read to pick up the final partial block. Here is the code:
$readSize = &min($bytesLeft, $blockReadSize);
$bufferLength = length($buffer);
$bytesRead = sysread(STDIN, $dataRead, $readSize);
&html("bytesRead=[$bytesRead . $bufferLength . $dataRead]") if ($debug);
if (!(defined $bytesRead)) {
$bytesRead = 0;
}
$buffer .= $dataRead;
In the last loop, the values that are returned in the debug statement are: 674 . 3268 .
So sysread says that 674 bytes were read, however $dataRead is empty. Both read and sysread exhibit the same behavior, returning the right number of bytes to be read, but not populating the variable with the actual data. This code works fine in versions of Perl other than Apache modperl. Has anyone experienced this behavior and have any suggestions?
Re: The procedure entry point for modperl_global_request could otbe located in the dynamic link library mod_perl.so.
On Tue, 4 Mar 2003, Richard Heintze wrote: > I downloaded > http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe > and ran the perl config.pl program. Since I received > so many errors (see end of this email message) I > decided to use my existing perl at c:\Perl\bin which > is a version of 5.8 that is already in my path. I've snipped the output below, but actually those were all warnings, not errors - most are due to pod2html not finding things like a title in the pod, and the last one was CPAN.pm not understanding a TERM environment variable. These can all safely be ignored, > > When I start apache, I now get the error: "The > procedure entry point for modperl_global_request could > ot be located in the dynamic link library mod_perl.so. > "OK". That's because the mod_perl.so you're using in the Apache2 modules/ directory was compiled with a different Perl and/or Apache2 than the one in that's being picked up in your PATH. > I've tried everything short of building mod_perl > myself (including the perl mpinstall, the single line > ppm command and the repository command for ppm3). > > I'm trying to install Apache2 with mod_perl on perl5.8 > on windows and I'm getting nowhere because I cannot > seem to get a good copy of mod_perl. What am I doing > wrong? I'd suggest, first of all, getting rid of the various Apache and Perl installations you have, and starting afresh. If you previously had installed an Apache2 service, remove it by C:\Path\to\Apache2\bin\Apache.exe -n Apache2 -k uninstall Then, either get the Perl-5.8-win32-bin.exe all-in-one binary, and install from it the Perl/ subdirectory to C:\Perl and the Apache2/ subdirectory to C:\Apache2. Alternatively, get an ActivePerl 8xx binary from www.activestate,com and an Apache2 binary from www.apache.org and install these, respectively, to C:\Perl and C:\Apache2. If you do the latter, then install the mod_perl ppm package as you've done before. -- best regards, randy
Re: Problems installing mod_perl2 on Apache2 on Win200
On Mon, 3 Mar 2003, Richard Heintze wrote: > Apache HTTPD seems to be running fine. > > Do I have the right version of apache and mod_perl? > I'm unpacking mod_perl2.tar. "perl mpinstall" does not > seem to be giving me any errors. The current mod_perl ppm package was compiled against Apache 2.0.44, so you should have at least 2.0.43. To see what version you have, do a C:\Path\to\Your\Apache2\bin\Apache.exe -v > > Apache installed itself in the directory program > files/apache group/apache2 so I think this means I'm > running apache2. > > What should I do next? Maybe I should build mod_perl > myself. Which compiler do you recommend for building > mod_perl on NT4 or Windows 2000? If you're running ActivePerl, you should use Visual C++ 6, for binary compatibility. Unfortunately, this isn't free ... There are free compilers for Win32 (eg, Borland, cygwin), but to use these you should compile everything (Perl and Apache2) with it. -- best regards, randy
internal_redirect and returns
I have a login system based on Apache::AuthCookie.
The handler for a location is set like this:
AuthType Thermeon::AuthHandler
AuthName Thermeon
SetHandler perl-script
PerlHandler Thermeon::AuthHandler->login
login isn't defined in Thermeon::AuthHandler - so the call passes up the ISA
to Apache::AuthCookie->login, as expected.
login does some funky stuff, calling auth subroutines ... eventually it
will, under some circumstances, do this:
return $auth_type->login_form;
This might be entirely familiar to everyone - but I thought I'd explain what
I understand is going on so that if you've never seen it before you don't
have to look it up,
or if I've got it wrong you can correct me :D
Now - my system isn't done yet.
It might still want to do some other stuff - under other circumstances.
Most of it's stuff is ok - but I get problems when I want to do an internal
redirect to another page.
I use this subroutine:
sub let_through {
my ($self, $r, $p) = @_;
$r->set_handlers( PerlAuthzHandler => [\&OK] );
$r->set_handlers( PerlAuthenHandler => [\&OK] );
$p && $r->internal_redirect( $p );
return OK;
}
And under some circumstances might call:
return $self->let_through( $r, $login_page );
for instance.
When this happen I find that the page shows ( $login_page ), but the browser
continues to show loading.
I check the error log and find:
message type 0x50 arrived from server while idle
If I request the $login_page directly through it's url - it works fine, no
error message and no browser continued loading.
The page that's being loaded does contain an iframe.
The iframe is also subject to the same auth handler - but a line catches it
with an exception and calls $self->let_through( $r ).
The error meass age ( message type 0x50 arrived from server while idle )
shows in the error log after this - if that helps.
Any ideas ?
Thanks
Gareth Kirwan
Programming & Development,
Thermeon Europe Ltd,
[EMAIL PROTECTED]
Tel: +44 (0) 1293 864 303
Thermeon Europe e-Card: gbjk
--
This message has been scanned for viruses and
dangerous content by Thermeon Europe using MailScanner,
and is believed to be clean.
Re: file upload under mod_perl 2 wihout CGI.pm
On Tue, 4 Mar 2003, Egor Korablev wrote:
> Hello.
>
> How can I get file upload from form using mod_perl 2 without CGI.pm?
>
> thx
You can't. At least not in an easy way, which I guess is what you want.
Apache::Request is not ported to mod_perl 2 yet. Time to fall back in love
with CGI.pm, just like when you were a young man and the web was even
younger :)
- nick
--
Nick Tonkin {|8^)>
file upload under mod_perl 2 wihout CGI.pm
Hello.How can I get file upload from form using mod_perl 2 without CGI.pm?thx
Re: prompting for secure data during startup.pl
Or simply unpack() which can also read directly from memory (demonstrated at http://www.greentechnologist.org/wiki/wiki?PerlSvInternals). Josh Perrin Harkins <[EMAIL PROTECTED]> 03/03/2003 01:05 PM To: "Aaron J. Mackey" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: prompting for secure data during startup.pl Aaron J Mackey wrote: > I need to make some secure data available to mod_perl handlers, without > having it physically stored in a file, database, or "named" shared memory > (since if someone can read the handlers' code, then they could read the > sensitive data as well). So I need to prompt for it during server > (re)start-up, and stuff it away into a lexical variable that only the > handler can get at (i.e. another piece of code, or even another handler, > that blesses itself into my handler's package still cannot access the > data). Every httpd child process should have their own copy of the data. > Is there a solution or cookbook recipe for this yet? What you're doing looks fine, as far as it goes. By making these variables part of a closure, you are making it impossible for people to read it directly with Perl code. Of course there is nothing you can do to prevent someone with full access to your server from running C code that will walk Perl's variables until it finds $secret. They could probably do this with creative of some of the B:: modules. - Perrin
The procedure entry point for modperl_global_request could ot be located in the dynamic link library mod_perl.so.
I downloaded http://theoryx5.uwinnipeg.ca/pub/other/Perl-5.8-win32-bin.exe and ran the perl config.pl program. Since I received so many errors (see end of this email message) I decided to use my existing perl at c:\Perl\bin which is a version of 5.8 that is already in my path. When I start apache, I now get the error: "The procedure entry point for modperl_global_request could ot be located in the dynamic link library mod_perl.so. "OK". I've tried everything short of building mod_perl myself (including the perl mpinstall, the single line ppm command and the repository command for ppm3). I'm trying to install Apache2 with mod_perl on perl5.8 on windows and I'm getting nowhere because I cannot seem to get a good copy of mod_perl. What am I doing wrong? Thanks, Siegfried Here are some of the errors from typing perl config.pl. I already had a good installation of Perl5.8 at c:\Perl\bin so I decided not to move \Program files\Apache Group\Perl to c:\Perl. When I received a lot of errors, I tried using the managed filename format (C:/PROGRA~1/APACHE~1/) but that did not help. - at =head in paragraph 1205. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unexpected =item directive in paragraph 1206. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unterminated list at =head in paragraph 1228. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unexpected =item directive in paragraph 1229. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unterminated list at =head in paragraph 1233. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unexpected =item directive in paragraph 1289. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unterminated list at =head in paragraph 1304. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unexpected =item directive in paragraph 1306. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unterminated list at =head in paragraph 1318. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unexpected =item directive in paragraph 1384. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ASP.pm: unterminated list at =head in paragraph 1977. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/AuthDBI.pm: unexpected =i tem directive in paragraph 146. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/AuthDBI.pm: unterminated list at =head in paragraph 184. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/AuthDBI.pm: unexpected =i tem directive in paragraph 206. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/AuthDBI.pm: unterminated list at =head in paragraph 209. ignoring. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/BuildConfig. pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/CmdParms.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Command.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/compat.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Connection.p m. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Const.pm. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/DBI.pm: unexpected =item directive in paragraph 76. ignoring. installhtml: C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/DBI.pm: unterminated list at =head in paragraph 79. ignoring. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Directive.pm . installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Filter.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/FilterRec.pm . installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/HookRun.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Log.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Mason.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Module.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ParseSource. pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/PerlSection. pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Process.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Reload.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/RequestIO.pm . installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/RequestRec.p m. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/RequestUtil. pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Response.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/Server.pm. installhtml: no title for C:/PROGRA~1/APACHE~1/Perl/site/lib/Apache/ServerUt
Re: Apache::DBI on mp2
On Today at 11:16am, SB=>Stas Bekman <[EMAIL PROTECTED]> wrote: SB> FWIW, we are discussing the internal DBI pooling mechanism at the SB> dbi-dev list and having already a sort-of-working prototype. So SB> hopefully there will be no need for Apache::DBI in the near future, as SB> DBI will be able to handle pooling internally. However it may take SB> some time, as the drivers will have to adjust to support the new SB> functionality. SB> SB> You can see the thread here: SB> http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB> SB> Some working examples are attached to this message: SB> http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB> Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. SB> [..snip..] SB> SB> If you apply the following patch (will commit it soon) against the modperl-2.0 SB> source, you will be able to use connect_on_init unmodified, assuming that SB> Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB> you. SB> I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Cheers, -- Haroon Rafique <[EMAIL PROTECTED]>
AuthCookie with a modified version of Authticket unable to delete the cookie (logout)
Hi All,
I am having problems using Authcookie 3.0 and a modified version of
AuthTicket 0.31
The problem is that I am not able to log off (delete the cookie). This is
frustrating :-(
I have everything else working correctly. Here is what I have done:
In my http.conf file I have defined the appropriate directives:
PerlModule Apache::AuthCookie
PerlModule Apache::PLMSolutions
PerlSetVar Apache::PLMSolutions /
PerlSetVar PLMSolutionsLoginScript /PLMSolutionsloginform
PerlSetVar PLMSolutionsLogoutScript /PLMSolutionslogout
PerlSetVar PLMSolutionsTicketLoginHandler /PLMSolutionslogin
PerlSetVar PLMSolutionsLoginScript /PLMSolutionsloginform
PerlSetVar AuthCookieDebug 3
AuthType Apache::PLMSolutions
AuthName PLMSolutions
PerlAuthenHandler Apache::PLMSolutions->authenticate
PerlAuthzHandler Apache::PLMSolutions->authorize
require valid-user
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
Perlhandler Apache::PLMSolutions->login_screen
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
PerlHandler Apache::PLMSolutions->login
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
PerlHandler Apache::PLMSolutions->logout
Ok, I have created a PLMSolutions.pm module located in
perl5.8.0/lib/site_perl/5.8.0/Apache
directory with this logout function defined as follows:
sub logout{
my ($class, $r) = @_;
my $this = $class->new($r);
$this->SUPER::logout($r);
$r->err_headers_out->add('Location' => $this->{TicketLogoutURI});
return REDIRECT;
}
On my HTML form I have defined the logout as this:
In the apache error_log file I have this listed:
Tue Mar 4 06:29:51 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:29:52 2003] PerlHandler subroutine
`Apache::PLMSolutions->login_screen': returning [/PLMSolutionslogin] for
TicketL
oginHandler at /app/perl5.8.0/lib/site_perl/5.8.0/Apache/PLMSolutions.pm
line 140.
[Tue Mar 4 06:29:52 2003] [error] REASON FOR AUTH NEEDED: no_cookie
[Tue Mar 4 06:29:52 2003] [error] AUTHTICKET REASON:
[Tue Mar 4 06:30:01 2003] [error] credential_0 hillr
[Tue Mar 4 06:30:01 2003] [error] credential_1 br3828
[Tue Mar 4 06:30:01 2003] [error] ses_key hillr:Ron Hill
[Tue Mar 4 06:30:01 2003] [error] auth_type Apache::PLMSolutions
[Tue Mar 4 06:30:01 2003] [error] auth_name PLMSolutions
[Tue Mar 4 06:30:01 2003] [error] ses_key_cookie hillr:Ron Hill
[Tue Mar 4 06:30:01 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:30:01 2003] [error] user authenticated as hillr
[Tue Mar 4 06:30:01 2003] [error] requirement := valid-user,
[Tue Mar 4 06:30:07 2003] [error] auth_type Apache::PLMSolutions
[Tue Mar 4 06:30:07 2003] [error] auth_name PLMSolutions
[Tue Mar 4 06:30:07 2003] [error] ses_key_cookie hillr:Ron Hill
[Tue Mar 4 06:30:07 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:30:07 2003] [error] user authenticated as hillr
[Tue Mar 4 06:30:07 2003] [error] requirement := valid-user,
Wherever I click the logout button on my form the script just returnes me
to the currect screen I was expecting to go to www-gtac (since that is what
I have defined in the TicketLogoutURI ).
Can someone point out what I am doing wrong? (and how to fix it).
One other question, how can I change the name of the cookie?
(currently is is Apache::PLMSolutions_PLMSolutions)
Thanks for any help you can provide.
Ron Hill
Re: $r->headers_in->get('Referer') doesn't work with IE
But with IE 6.0 the $r->uri and $r->headers_in->get('Referer') is
different than for NN.
as you're seeing, the Referer header is pretty unreliable due to the
different ways browsers implement it.
you should probably switch to a different method for this, such as
specifying the environment through a PerlSetVar, or maybe passing it around
in a form field, the query string, or extra path info or something.
HTH
--Geoff
$r->headers_in->get('Referer') doesn't work with IE
Hi,
I using recipe 10.4 from the mod_perl cookbook.
in
sub logout ($$) {
# I'm setting the logout address to be the login page again. My login page
# is made up of /bin/$environment_name/
# With Netscape it works fine ..
my ($self, $r) = @_;
my $uri = $r->headers_in->get('Referer') ;
my @split = split /\//, $uri ;
my $db = $split[4] ;
$self->SUPER::logout($r);
my $logout_address = "/bin/" . $db . "/" ;
$r->headers_out->set(Location => "$logout_address");
return REDIRECT;
}
Checking the log file for netscape everything is as expected.
User can login, work, logout -> back to login page ready for next user.
But with IE 6.0 the $r->uri and $r->headers_in->get('Referer') is
different than for NN. It is the next page being called in this case just
/logout so I no longer know what was my db value.
Any ideas how to solve this?
Scott
Re: Apache is exiting....
On Mon, 3 Mar 2003 13:36:05 + (GMT) Ged Haywood <[EMAIL PROTECTED]> wrote: > Hi there, > > On Mon, 3 Mar 2003, Paolo Campanella wrote: > > > gdb reports that clean_child_exit is not defined - perhaps you are > > looking at newer sources than mine (1.3.22). > > Is there a reason why you don't want to upgrade to 1.3.27? Have now tried 1.3.27 - no difference.
Re: Apache is exiting....
On Mon, 3 Mar 2003 13:36:05 + (GMT) Ged Haywood <[EMAIL PROTECTED]> wrote: > Hi there, > > On Mon, 3 Mar 2003, Paolo Campanella wrote: > > > gdb reports that clean_child_exit is not defined - perhaps you are > > looking at newer sources than mine (1.3.22). > > Is there a reason why you don't want to upgrade to 1.3.27? I'm quite tied in to RedHat RPMS, which I've had to customise and install across various servers. So I need to upgrade sometime, but it's not something I can undertake lightly. I will test it soon though & let the list know if it made any difference.
RE: make errors with mod_perl-1.99_08 on aix 4.3.3 & 5.1
I've been following this thread for a few days now, and I just thought that I'd mention that this compile problem appears to be the same on AIX 5.1 ML02 with C for AIX 6.0. I may be able to offer access to this system for one individual to assist in the process of debugging this, since it's been mentioned that access to an AIX boxen is a problem. -JD. At 5:02 PM -0500 3/3/03, Priest, Darryl - BALTO wrote: #> I got the new CVS version applied the patch and I got a bit further # #good, I've committed that patch. # #>, but #> it's still dying with: #> #> cd "src/modules/perl" && make -f Makefile.modperl #> rm -f mod_perl.so #> ld -bhalt:4 -bM:SRE #> -bI:/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/perl.exp -bE:mod_perl.exp #> -bnoentry -lc -L/usr/local/libmod_perl.lo modperl_interp.lo #> modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo #> modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo #> modperl_util.lo modperl_io.lo modperl_filter.lo modperl_bucket.lo #> modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo #> modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo #> modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo #> modperl_constants.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo #> modperl_xsinit.lo -bE:/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/perl.exp #> -brtl -L/usr/local/lib -b32 #> /usr/local/perl5.8.0/lib/5.8.0/aix/auto/DynaLoader/DynaLoader.a #> -L/usr/local/perl5.8.0/lib/5.8.0/aix/CORE -lperl -lbind -lnsl -ldl -lld -lm #> -lc -lcrypt -lbsd -lPW -o mod_perl.so #> ld: 0706-004 Cannot find or read export file: mod_perl.exp #> ld:accessx(): A file or directory in the path name does not exist. #> make: 1254-004 The error code from the last command is 255. # #> To get that far, in the src/modules/perl/Makefile.modperl I added #> definitions for BASEEXT and PERL_INC, as copied from modperl-2.0/Makefile, #> as shown below, since they were missing. # #why would you need them? I mean what was the error that you had to add them? Without PERL_INC I got this error: ld -bhalt:4 -bM:SRE -bI:/perl.exp -bE:.exp -bnoentry -lc -L/usr/local/libmod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo -bE:/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/perl.exp -brtl -L/usr/local/lib -b32 /usr/local/perl5.8.0/lib/5.8.0/aix/auto/DynaLoader/DynaLoader.a -L/usr/local/perl5.8.0/lib/5.8.0/aix/CORE -lperl -lbind -lnsl -ldl -lld -lm -lc -lcrypt -lbsd -lPW -o mod_perl.so ld: 0706-003 Cannot find or read import file: /perl.exp ld:accessx(): A file or directory in the path name does not exist. ld: 0706-004 Cannot find or read export file: .exp ld:accessx(): A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 255. So, I looked at the -bI:/perl.exp and looked at the Makefile.modperl and saw that it referenced PERL_INC, which didn't appear to be defined, although it was referenced, after setting it to PERL_INC = /usr/local/perl5.8.0/lib/5.8.0/aix/CORE and got this error next: ld -bhalt:4 -bM:SRE -bI:/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/perl.exp -bE:.exp -bnoentry -lc -L/usr/local/libmod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo -bE:/usr/local/perl5.8.0/lib/5.8.0/aix/CORE/perl.exp -brtl -L/usr/local/lib -b32 /usr/local/perl5.8.0/lib/5.8.0/aix/auto/DynaLoader/DynaLoader.a -L/usr/local/perl5.8.0/lib/5.8.0/aix/CORE -lperl -lbind -lnsl -ldl -lld -lm -lc -lcrypt -lbsd -lPW -o mod_perl.so ld: 0706-004 Cannot find or read export file: .exp ld:accessx(): A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 255. Noticed -bE:.exp and looked in the makefile for where that was coming from, which led me to set BASEEXT = mod_perl since it was defined in Makefile.modperl but was referenced. Which led a bit further but still without success. # #> BASEEXT = mod_perl # #what if you replace it
Re: [mp2] disabling a perl handler within a specific location
Hi!
On Tue, Mar 04, 2003 at 12:54:30AM -0500, Matt Avitable wrote:
> Does anyone know how one goes about disabling a particular handler
> within a specific location? For example, consider the following:
>
>
> PerlInitHandler config
> PerlOutputFilterHandler filter
>
>
>
> ## what can I put here to say "don't run" to the above handlers?
>
This works for Auth*Handlers, so it should work for any phase:
PerlInitHandler Apache::Constants::OK
See recipy 7.3 in the Cookbook
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
