Re: [mp1] .htaccess and mod_perl
Geoffrey Young wrote: Apache::StatINC is R.I.P. Use Apache::Reload instead. but Apache::StatINC comes with mp1 and Apache::Reload doesn't - it's difficult to install modules on these ensim boxes since you don't have root (and yes, there are other ways around it of course :) We could bundle Apache::Reload with 1.28 I suppose. __ 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: [error] Can't locate CGI.pm in @INC
Brown, Jeffrey wrote: I have installed OpenBSD 3.2, with Apache 1.3.26, and mod_perl 1.26 which was installed as a package. I have rebooted, stopped and started apache. I have permissions of 755 on my perl scripts and here is my error log: [Wed May 28 19:33:57 2003] [error] Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib/site_perl/5.6.1/i386-openbsd /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl . /var/www/ /var/www/lib/perl) at /htdocs/perl/hellothere.pl line 3 during global destruction. BEGIN failed--compilation aborted at /htdocs/perl/hellothere.pl line 3 during global destruction. global destruction? When I do a find for CGI.pm here are the results: as07# find / -name CGI.pm /usr/libdata/perl5/CGI.pm /usr/libdata/perl5/ is in @INC. Check CGI.pm perms. See that it is readable by the user that is running the server. __ 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: Can't use sendmail more than once
Perrin Harkins wrote: On Wed, 2003-05-28 at 22:45, Greg Dutkowski wrote: I have migrated my site from IIS and Active State to Apache 1.3 and mod_perl on a Windows machine. I use the site to send emails to registered users using Mail::sendmail through our SMTP server (another machine). With Apache I can only send emails once after I start the Apache server, thereafter it tells me it can't connect to the SMTP server. Restarting the Apache server leads to again being able to only send emails once. Any ideas? This is a known problem with mod_perl 1.x on Win32. Sockets only work when you make it single-threaded (ThreadsPerChild 1). Doing that doesn't make a difference in terms of your actual script performance, since mod_perl is already single-threaded on Win32, but it will make images slow. One solution is to serve the images from a separate web server. Can we add this factoid to http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Windows_OS_specific_notes ? __ 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: [mp1] .htaccess and mod_perl
Michael L. Artz wrote: Apache::StatINC is R.I.P. Use Apache::Reload instead. but Apache::StatINC comes with mp1 and Apache::Reload doesn't - it's difficult to install modules on these ensim boxes since you don't have root (and yes, there are other ways around it of course :) Well, Apache::StatINC wasn't distributed with the install of mod_perl that I was using (1.24) or else it wasn't in the global @INC, so I just snapped up the source from cpan and put it (with an addition to @INC) locally in my ensim tree. eh? It's been in the distro for the last 6 years or so. But Apache::Reload is a way to go. mp2 has only it. So it's better to get used to it. I will try and get Apache::Reload working, since Stas says so :) I think that I can install any module that doesn't need a compiler, although the whole 'make test' thing might get me since I don't have access to the httpd binary. Who needs testing anyway? I don't think it has a test suite anyways. __ 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] new utils mp2bug and mp2doc and more ModPerl::MethodLookupmethods
I forgot to mention that 1.99_09 installs two new utils: - mp2bug: used for success/failure reports after mod_perl was installed and the source is no longer available (e.g. binary distros). - mp2doc: replaces perldoc to cope with the Apache2/ subdir (perldoc won't know to search under Apache2)/. So now you can do things like: % mp2doc Apache::Filter Also ModPerl::MethodLookup has new useful features: print_object() and print_module() (there is also non-print API): % perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::RequestRec Objects of type 'Apache::RequestRec' can invoke the following XS methods: MethodModule - BINMODE Apache::RequestIO CLOSE Apache::RequestIO [many more snipped] % perl -MApache2 -MModPerl::MethodLookup -e print_module Apache::RequestRec Module 'Apache::RequestRec' contains the following XS methods: Method Invoked on object type allowed Apache::RequestRec allowed_methods Apache::RequestRec [many more snipped] For more info see: http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html __ 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 2.0.46 works
Carl Brewer wrote: I've just spun up apache 2.0.46 on Solaris 8, and the install of mod_perl 1.99_09 seems fine so far. Great. Thanks Carl! For those who post success reports (which are as important as failure notes), please either include the output of mp2bug (added in 1.99_09 to replace t/REPORT which won't be available after 'make install') or at least mention perl version and apache mpm 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: [error] Can't locate CGI.pm in @INC
Brown, Jeffrey wrote: Problem solved! You all are a fantastic resource to newbies! Jeff -Original Message- From: Ed [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:28 PM To: Brown, Jeffrey; [EMAIL PROTECTED] On Wed, May 28, 2003 at 09:11:06PM -0700, Brown, Jeffrey wrote: Here are the results from the log file: [Wed May 28 20:50:21 2003] [error] No such file or directory at /htdocs/perl/first.pl line 6 during global destruction. openbsd's httpd is chrooted. Again, can someone please post a patch/addition for the troubleshooting.pod doc explaining the problem and the solution in details. I've seen this kind of questions more than once here. Should go into OpenBSD cat at: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#OS_Specific_Notes Get the pod by clicking on the [src] button. __ 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] a better way to block/throttle clients
mod_perl 1.0 has several tools for throttling/block clients, but they all do
their work in pretty late stage, wasting quite a few resources. With mp2 you
can now throttle/block clients before any data was sent and before Apache has
done anything at all. This example module takes advantage of running during
the pre_connection phase. I believe this is almost as efficient as firewall
blocking (the only overhead is select() and several calls in perl). the cool
thing is that Apache simply drops the connection without sending anything back
to the client ;)
Of course you want to adopt it to use a real database and some well defined
blocking policies. May be Randal will revise his webtechnique column to use
this better phase (CC'ing him).
#file:MyApache/BlockIP2.pm
#--
package MyApache::BlockIP2;
use Apache::Connection ();
use Apache::Const -compile = qw(FORBIDDEN OK);
my %bad_ips = map {$_ = 1} qw(127.0.0.1 10.0.0.4);
sub handler {
my Apache::Connection $c = shift;
my $ip = $c-remote_ip;
if (exists $bad_ips{$ip}) {
warn IP $ip is blocked\n;
return Apache::FORBIDDEN;
}
return Apache::OK;
}
1;
Configuration:
PerlPreConnectionHandler MyApache::BlockIP2
You will need mp 1.99_08 or higher for this to work.
__
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: Boatload of warning messages
Perrin Harkins wrote:
On Tue, 2003-05-27 at 16:28, Dale Lancaster wrote:
I have combed the various docs and haven't yet found the silver bullet
to turn off all the warnings I am getting from mod_perl in my
error_log that look something like this:
Constant subroutine
Apache::ROOTusa_2eusahire_2ecom::cgi_2dbin::portal::gojobs::gojobs_2ecgi::RC_CONTINUE
redefined at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/PerlRun.pm
line 361.
I have tried:
PerlWarn Off in the httpd.conf file
no warnings ; in the startup.pl
no strict ; in the startup.pl
It should work to do this:
no warnings qw(redefine);
These are lexically scoped, so if your script has a use warnings or -w
in it, they will get turned back on.
This is not the case with constant subs. Perl 5.8.0+ provides no facilities to
shut it off, on purpose. The only way to avoid these warnings is to install
this trap:
$SIG{__WARN__} = \skip_redefine_const_sub_warn;
sub skip_redefine_const_sub_warn {
return if $_[0] =~ /^Constant subroutine [\w:]+ redefined at/;
CORE::warn(@_);
}
I'm now fixing Apache::Reload to have a special config option to enable this
feature. This can't be turned off by default, because it may result in
unexpected behavior if the constant sub was modified for real. So a special
option for those who know what are they doing will be provided.
Note that this only happens when you cause PerlRun to reload a script
that defines constants. Restarting the server as described in the docs
avoids the issue:
http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Constant_subroutine_XXX_redefined
I'll update this section with the above info.
__
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] Authentication/Authorization modules
Michael L. Artz wrote: I am fairly new to mod_perl/apache, having grown up with OpenACS and AOLServer. I have read all of the docs on the web site (I think) and had a whole authentication/authorization scheme planned out using Apache::AuthCookie and Apache::Session. I was just put in charge of a beta web application (database backed, user preferences, etc), and would like to use Apache2/mp2 for it. I came to find that AuthCookie doesn't seem to be ported to mp2, so my origianal authorization plan went up in shambles, not to mention all of the other stuff that I have read (eagle book, developer's cookbook) seems to be centered around mp1 and libapreq. My newbie question is then, what would the best way to implement an authorization scheme in mp2 and are there any helpful modules ported? I am thinking of something pretty standard, like what Apache::AuthCookie provides with a DB backend verifying the user/pass. I attempted to implement something like recipe 13.7 (from the cookbook) using CGI::Cookie instead of Apache::Cookie, but CGI complained about not being able to find Apache.pm. I assume that I just need a newer version (using stock RH8.0 with new apache and mod_perl). You should be able to use CGI::Cookie with the latest CGI.pm and the latest mod_perl (1.99_08 or cvs). Certainly it'd be helpful for module authors to start porting their modules to mp2. __ 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: Problem adding mod_perl to my web server config.
Paul Adair wrote: I recently attempted to add mod_perl to my web server configuration. Here is my current web server info. Apache/2.0.44 (Unix) mod_ssl/2.0.44 OpenSSL/0.9.7a DAV/2 PHP/4.3.1 Sun-ONE-ASP/4.0.0 There are no problems with this config and everything work ok. Paul, please make sure to follow the bug reporting guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I went through all of the config/setup docs on the web. I received an error while doing the make test. The error seemed to be tied with the mod_casp2 modules for Sun Chilisoft ASP. I figured maybe it has never tested it with this module so I proceeded with the make install. The make install seemed to go ok and it placed the mod_perl.so file in my apache2/modules directory. I then added the LoadModule mod_perl modules/mod_perl.so to my httpd.conf file. When attempting to start the web server I get the following error. you mean the one at the bottom of your bug report? I went through as much of the documentation that I could and I cannot find anything wrong at this time. Is there something else that needs to run at the end of the make test that my server did not complete because of the mod_casp2 problem? Is it possible that Apache::Test has picked mod_casp2 module from your already installed httpd's httpd.conf? Can you check whether you have the mod_casp2 module configured in t/conf/httpd.conf after you run: t/TEST -conf (that's after you've run 'make') If you have, does removing that entry allow the tests to start and pass? t/TEST (not 'make test', as it'll rewrite t/conf/httpd.conf again) __ 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] adding SERVER_ROOT and SERVER_ROOT/lib/perl to @INC
I've committed the code that adds SERVER_ROOT and SERVER_ROOT/lib/perl to @INC, but it's disabled if an explicit MP_COMPAT_1X=0 is passed to Makefile.PL (it's enabled by default). I'll document shortly what other mp1-compat features can be disabled by passing MP_COMPAT_1X=0... __ 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
centralized docs (was Re: [mp2.0] W2000, Apache 2.0.43 + mod_perl1.99_09 does not start)
Jean-Michel Hiver wrote: Hello, We have a problem getting mod_perl to run on a W2000 server. It does work on another machine running WinNT4, so I think there are no errors in my configuration files. Actually I'm having a windows machine at home and I got mod_perl working with ActiveState perl. I've written a howto on my personal website. You might want to try check it out, hopefully it will prove useful :) http://www.webmatrix.net/log/modperl-win32/ May I suggest that everybody benefits from having a single documentation source? Jean-Michel, I'm not sure about this excerpt: Documentation is hard to find out there so I decided to write this little howto in order to save other people this hassle... Randy Kobes is doing a fantastic job maintaining win32 docs for both mod_perl generations. mp1: http://perl.apache.org/docs/1.0/os/win32/index.html mp2: http://perl.apache.org/docs/2.0/os/win32/index.html IMHO, it's so much better to put the joined forced to produce unified docs, rather than having them scattered all over web. Jean-Michel, if something is missing/wrong from the docs whose URLs I've listed, can you please submit a doc patch to improve the existing documentation? Thank you! We need all the help we can get with writing/improving documentation. So if you feel like helping send the patches in. If you feel like you want to take an ownership over your favorite docs, please do so. e.g. Nick Tonkin has done a great job working on the porting document for mod_perl 2.0 (it wasn't integrated yet, hopefully will be soon). Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] upload file
Udlei Nattis wrote:
fix problem
i need change SetHandler modperl to perl-script, now upload is ok
why this happens? i need add any options in SetHandler modperl to use
upload ?
Please read:
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
Do you say that you have no errors logged in error_log while using 'SetHandler
modperl'? You should, because Apache-request dies if called under 'SetHandler
modperl' and no 'PerlOptions +GlobalRequest'
I can see why the env reading was failing. We need to patch CGI.pm to die when
the configuration is:
PerlOptions -SetupEnv
(which is effective with 'SetHandler modperl'), though we don't have the API
to do so yet. Once I'll finish the filter API, I'll work on the perloptions
API and then we will patch CGI.pm to do this check.
Meanwhile I believe CGI.pm can be patched to check for some cgi env var (e.g.
$ENV{QUERY_STRING}) and if it's not there run $r-subprocess_env, which is in
effect the same as 'PerlOptions +SetupEnv'. Can you give a try to this while
keeping the setting 'SetHandler modperl':
# CGI.pm
sub new {
my($class,$initializer) = @_;
my $self = {};
bless $self,ref $class || $class || $DefaultClass;
if ($MOD_PERL) {
my $r = Apache-request;
if ($MOD_PERL == 1) {
$r-register_cleanup(\CGI::_reset_globals);
}
else {
# PerlOptions -SetupEnv check
# XXX: this should be really replaced with a check
# of the SetupEnv perloptions check, once the API is available
$r-subprocess_env unless exists $ENV{QUERY_STRING};
$r-pool-cleanup_register(\CGI::_reset_globals);
}
undef $NPH;
}
$self-_reset_globals if $PERLEX;
$self-init($initializer);
return $self;
}
the change is:
$r-subprocess_env unless exists $ENV{QUERY_STRING};
__
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] make test errors
Paul Simon wrote:
Is this something to be worried about? Or can I
continue with make install? Please help.
Probably not unless you use APR::PerlIO and APR::ThreadMutex, so you can go
with 'make install'.
However let's solve the problems nevertheless.
Could you first install the latest cvs, so we can work with the same version.
I've mapped the failures to the error_log entries:
apr/perlio.t11 11 100.00% 1-11
mkdir /usr/src/mod_perl-1.99_08/t/htdocs/perlio:
Permission denied at
/usr/src/mod_perl-1.99_08/Apache-Test/lib/Apache/TestUtil.pm
why do you have a perm problem? Do you run the test as root? What are the
perms of /usr/src/mod_perl-1.99_08/t/htdocs
/usr/src/mod_perl-1.99_08/t/htdocs/perlio
apr/threadmutex.t33 100.00% 1-3
[Thu Apr 03 19:40:50 2003] [error] [client 127.0.0.1]
Can't locate APR/ThreadMutex.pm in @INC (@INC
contains: /usr/src/mod_perl-1.99_08/t
If you look at t/response/TestAPR/threadmutex.pm. It runs this check:
plan $r, tests = 3, have_threads;
The have_threads function (which lives in Apache-Test/lib/Apache/Test.pm)
checks these predicaments:
$apr_config-{HAS_THREADS}
$Config{useithreads} eq 'define';
mod_perl build code (which lives in lib/ModPerl/BuildMM.pm) skips building
APR::ThreadMutex if apr doesn't have HAS_THREADS defined.
if ($path =~ m/(Thread|Global)Mutex/) {
return unless $apr_config-{HAS_THREADS};
}
It's strange that the build saw that apr has no HAS_THREADS, while the test
saw the opposite.
Can you do (adjust the path to the include dir of the httpd server):
grep HAS_THREADS ~/httpd/prefork/include/apr.h
and also run (with the same perl):
perl -V:useithreads
__
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.0] make test failure in mod_perl 1.99_08
Can you give it a try with the latest cvs, without the changes you have applied? Thanks. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution __ 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.0] make test failure in mod_perl 1.99_08
Hensley, Richard wrote: Unfortunately, I can not access cvs from behind the corporate firewall. I was using the contents of mod_perl-2.0-current.tar.gz, which is the best I can do. Sorry. You can get the latest cvs snapshots here: http://cvs.apache.org/snapshots/modperl-2.0/ I'll update the doc to include this URL. __ 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.0] make test failure in mod_perl 1.99_08
Stas Bekman wrote:
Hensley, Richard wrote:
Unfortunately, I can not access cvs from behind the corporate
firewall. I was using the contents of mod_perl-2.0-current.tar.gz,
which is the best I can do. Sorry.
You can get the latest cvs snapshots here:
http://cvs.apache.org/snapshots/modperl-2.0/
You will also need to apply this patch after you download the snapshot, unless
you pick the snapshot 5 hours from now, which will already include it.
Thanks to Geoff for the heads up!
--- Apache-Test/lib/Apache/TestConfig.pm27 Mar 2003 07:57:06 -
1.148
+++ Apache-Test/lib/Apache/TestConfig.pm4 Apr 2003 00:27:47 -
@@ -113,7 +113,9 @@
sub server { shift-{server} }
sub modperl_2_inc_fixup {
-(eval { require mod_perl } $mod_perl::VERSION = 1.99)
+
+(eval { require mod_perl } $mod_perl::VERSION = 1.99
+ eval { require Apache::Build } !Apache::Build::IS_MOD_PERL_BUILD())
? use Apache2;\n
: '';
}
__
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: best way to configure for multiple developers?
Right, I guess it just feels like it is working under mp1, since I can get @INC to contain . (the current dir) and use StatINC in all the developer locations. In the mp2 server, it shows me a different @INC, that doesn't include . (is it possible in mp2?). You almost got me ;) I was looking for the place in mp2 that removes . from @INC. After awhile it struck me to check the perl source, and perl.c had: if (!PL_tainting) incpush(., FALSE, FALSE, TRUE); It's been there for a long time (tested with 5.005_03), though I didn't know/remember that :( # here you have . % perl -le 'warn join \n, @INC, ;' # and here you don't % perl -Tle 'warn join \n, @INC, ;' . is added to @INC only if you aren't running with -T. Nothing specific to mod_perl. You can still add it using: use lib qw(.); if you really have to. But it's especially bad idea with mp2/threaded mpm, where one should never use chdir during request time and rely on cwd. See: http://perl.apache.org/docs/2.0/user/coding/coding.html#Thread_environment_Issues __ 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.0] make test failure in mod_perl 1.99_08
Hensley, Richard wrote: I tried it with the lastest snapshot, and the patch below. I still get the following in the error_log [Thu Apr 03 16:49:00 2003] [error] failed to resolve handler `TestHooks::trans' [Thu Apr 03 16:49:00 2003] [error] [client 127.0.0.1] Can't locate TestHooks/trans.pm in @INC (@INC contains: /home/rhensle/modperl-2.0/t /usr/lib/perl5/site_pe rl/5.6.1/i386-linux/Apache2 /home/rhensle/modperl-2.0/Apache-Test/lib /home/rhen sle/modperl-2.0/lib /home/rhensle/modperl-2.0/blib/lib /home/rhensle/modperl-2.0 /blib/arch /home/rhensle/modperl-2.0/t/response /home/rhensle/modperl-2.0/t/prot ocol /home/rhensle/modperl-2.0/t/preconnection /home/rhensle/modperl-2.0/t/hooks /home/rhensle/modperl-2.0/t/filter /home/rhensle/modperl-2.0/t/htdocs/testdirec tive/main /home/rhensle/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /usr/li b/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i38 This was the second problem I encountered after I fixed the first.pm problem. I fixed this by adding a PerlModule TestHooks::trans to the httpd.conf in my original patches I sent. /home/rhensle/modperl-2.0/t/hooks is in @INC, any idea why it can't find TestHooks/trans.pm. What are the file perms for /home/rhensle/modperl-2.0/t/hooks/TestHooks/trans.pm? I don't seem to be able to reproduce the problem. I've tried using the same perl version as yours, with and without root, but in vain; It works. Do you get the error during server startup or when the actual tests are run? Can you remove the 'PerlModule TestHooks::trans' that you have added, rebuild mod_perl with MP_TRACE=1 (perl Makefile.PL MP_TRACE=1 ...) and now run: rm t/logs/error_log MOD_PERL_TRACE=h t/TEST -start (run 'env MOD_PERL_TRACE=h t/TEST -start' if using csh) do you get the failure? Post the output of the startup and the error_log file. If you didn't get the failure so far, next run: t/TEST -run hooks/trans and post only the error_log file. Since the trace is going to be pretty long, send it to me and not to the list. __ 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.0] make test failure in mod_perl 1.99_08
Hensley, Richard wrote: As an aside, one of the interesting issues that I ran across when running make test was the following: /usr/local/apache2/bin/httpd -d /home/rhensle/modperl-2.0/t -f /home/rhensle/mo dperl-2.0/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.44-dev (prefork MPM) waiting for server to start: .No -M allowed while running setuid. Most likely coming from t/conf/httpd.conf having: PerlSwitches -Mlib=/home/stas/apache.org/mp-filters/t does the problem disappear if you replace it with: PerlSwitches -I/home/stas/apache.org/mp-filters/t Why is your perl has setuid bits set? perl_parse: Address family not supported by protocol most likely an error in apr_parse_addr_port() but could be due to earlier problems. server has died with status 1 (please examine t/logs/error_log) what's your t/logs/error_log says? make: *** [run_tests] Error 143 I think this occurs because my apache2 is located in /usr/local/apache2 and installed by root. The user that I built mod_perl with is not root, therefore it sqawks. I overcame this by building mod_perl as root. I also had to run the tests as root, but I think that some of the tests will eventually fail in this mode. Tests should run just fine with root. Did you have any problems? __ 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] upload file
I used of examples these 2 archives but dont functioned in mp1 i dont have problem my mp2 version is last cvs version So you have a problem with mp2. Did you upgrade your CGI.pm to the latest version? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cgi.pm does not work in handlers (why responsehandlers at all?)
[EMAIL PROTECTED] wrote: thnx for your reply. I use mod_perl 2 (1.99_08) and CGI.pm 2.91 and Apache 2.0.44. I thought that CGI.pm wouldnt work at all, so I didnt give any examples. I wrote a simply script that checks if running under mod_perl, displays some parameter and evaluates/presents a form. This script (source below) I implement as simple mod_perl-script one time and as PerlResponseHandler the other time. As sole mod_perl-script it works perfect, while as Handler: [...] apache-config PerlModule goldfisch::apache::random Location /time SetHandler modperl This is your problem. CGI.pm relies on things like Apache-request and env vars, neither of which is available under 'SetHandler modperl'. Change it to 'SetHandler perl-script' and read: http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_ __ 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: How to make apache with both mod_perl and mod_ssl?
Charlie Smith wrote: How to make apache with both mod_perl and mod_ssl? RTFM: http://perl.apache.org/docs/1.0/guide/install.html#Installation_Scenarios_for_mod_perl_and_Other_Components __ 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::Request
Ewald Geschwinde wrote:
I have read that the param Method had been deprecated
$r-param('value'):
How do I get now the variables from a submitted form ??
now? when? nothing has changed with Apache::Request. No April Fools jokes 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
Re: [mp2] upload file
Udlei Nattis wrote: hi, i have problem for upload files testing use CGI and CGI::Simple look file.pm: $cgi = CGI-new; $r-print($cgi-param(test). xxx ); file .html form action=end method=post enctype=multipart/form-data input type=file name=image input type=hidden name=test value=abcdef input type=submit /form when i add enctype param(test) return undefined value and wne i remove enctype param(test) print abcdef my question is: why when i add enctype, param(test) return undefined value? Does the same program works with mp1? Do you use the latest mp2 (at least 1.99_08), better cvs? The 2.0 test suite has an upload file test (CGI.pm) and it works fine with the current mod_perl. Please look at the pair: t/modules/cgiupload.t t/response/TestModules/cgiupload.pm in the mod_perl source. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cgi.pm does not work in handlers (why responsehandlers at all?)
[EMAIL PROTECTED] wrote: I used CGI.pm in my mod_perl-application to get 'path_info', 'param', print out headers and more. None of this works inside my own handlers any more. Which mod_perl generation are you using? mod_perl 1.0 (1.27?) or mod_perl 2.0 (1.99_08?). I suspect that you use mp2, since you mention later ResponseHandler, which doesn't exist in mp1. If that's the case, are you using the latest CGI.pm version? (older versions are known not malfunction with mp2). If after getting the latest versions you still have problems, please post a *simple* several lines handler/script which doesn't work for you. Asking *why* CGI.pm doesn't work, is similar to asking why my car doesn't move from its place ;) You have to be more specific and then we will be able to figure out, what the problem is. - whats the maineffect of a simple ResponseHandler at all compared with a perl-program run under mod_perl ? Is it much faster, cause it handles things more efficiently ? By now I used to use an Alias-Directive in apache to direct certains requests to a single perl-script and use path_info() to detect the additional arguments. For the use there is no difference at all. If you are talking about perl-scripts running under Apache::Registry or Apache::PerlRun, you are in fact running response handlers. The scripts are converted to such behind the scenes. In addition registry scripts do a few more things, which slow things down just a tiny-bit, probably insignificant if you programs are big enough. If you want to explore more, you will find this information and a lot more at http://perl.apache.org/docs/. I discovered replacements like Apache::Request but I'm now sure if this would work inside a handler. Apache::Request works as a drop-in replacement for CGI.pm's request parsing for mp1. It's not yet available for mp2. __ 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: Recompiling Apache
Chris Faust wrote: Hello Group, I want to add the rewrite module to my apache and it would appear I have to recompile apache to do so.. Does this mean I'll need to redo mod_perl after Apache as well? RH 8 Apache 2.044 mod_perl 1.99.09 If it's a DSO module and you just add another module in without changing the core you don't need to recompile DSO. I believe you don't even need to recompile Apache itself, if mod_rewrite can be compiled as DSO, but I haven't tried that. __ 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: Off Topic but curious
John Michael wrote: If I bought a domain name with perl in it to build a perl script site, would I be infringing on any perl trademark or copyrights. Would it be ok or could I be told I couldn't use the domain. John, Please repost the question to the perl advocacy list. ([EMAIL PROTECTED]). In the future please refer to http://lists.perl.org to find an appropriate list to post non-mod_perl perl-related questions. Thank you. __ 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: [Question] Handler executing twice!?!
Vince Veselosky wrote: [...] Now here is the thing. The PerlHeaderParserHandler executes TWICE for every request. The second time through is apparently a different Apache Could it be that something in your code pushes the handler on the stack again? I'd suggest debugging with Apache::ShowRequest? http://search.cpan.org/author/DOUGM/Apache-Module-0.11/lib/Apache/ShowRequest.pm Do tracing: http://perl.apache.org/docs/1.0/guide/debug.html#Debug_Tracing Use the 'h' setting PerlSetEnv MOD_PERL_TRACE h Try to use $r-get_handlers() and see what you get. Finally, if nothing helps, go with gdb. Also what happens if you don't use Apache::Request? __ 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: installing mod_perl with Apache and mod_ssl
Richard Kurth wrote: Hello , I am trying to install mod_perl with Apache apache_1.3.27 mod_ssl-2.8.12-1.3.27 and Frontpage This is what I am doing to install it but for some reason mod_perl does not install properly. [...] This might help: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ -- __ 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: [Question] Handler executing twice!?!
Vince Veselosky wrote: [...] The thing that triggered it was the fact that the url was an index.pl file. When called as example.com/index.pl, everything worked as expected, but when called as example.com/, apache (or something) generated a subrequest for index.pl. NOW my question is, why does apache generate the subrequest *after* the HeaderParser phase, causing it to execute twice? This seems like a pure URI translation issue, and I would expect it to happen in the URI translation phase, *before* the HeaderParser executes at all. I'm wondering if this happens in all requests, or if it is related to Apache::Registry in the content handler. I didn't take the time to track down exactly where the subrequest originates, so I'm not sure if it is a mod_perl issue or just an apache issue. I might one day build some test cases and figure it out, but not soon. Anyone have some insight to add? Do you have mod_dir (DirectoryIndex) configured? It performs a rewrite/sub_request-redirect in the fixup stage. http://httpd.apache.org/docs/mod/mod_dir.html __ 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 1.99_09dev on AIX4.3.3
Stas Bekman wrote: ODELL, TODD E (SWBT) wrote: [...] ulimit -c unlimited; t/TEST -clean Error in option spec: verbose:1 make: 1254-004 The error code from the last command is 255. hmm, I've added yesterday a support for make test TEST_VERBOSE=1 TEST_FILES=..., this is a problem with Getopt::Long, looks like you have an older version, which doesn't support this feature (it was added in 2.27). Though don't upgrade. Let's see if this can be workarounded, since many others have older version of this module. Try this patch: sorry, that patch wasn't complete, as I haven't removed the rule itself. I've now committed the right fix to cvs. Please test it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make test fails - Solaris8, Perl5.8.0, mod_perl 1.99_08
Adrian Klingel wrote:
[...]
waiting for server to start: .[Thu Mar 27 16:50:41 2003] [crit] [Thu Mar 27
16:50:41 2003] file vhost.c, line 232, assertion rv == APR_SUCCESS failed
[...]
If anyone can help, please do. Any help is deeply appreciated!
This is the relevant code in vhost.c (httpd-side):
else if (strcasecmp(host, _default_) == 0
|| strcmp(host, 255.255.255.255) == 0) {
rv = apr_sockaddr_info_get(my_addr, 255.255.255.255, APR_INET,
port, 0, p);
ap_assert(rv == APR_SUCCESS); /* must be bug or out of storage */
}
so apr_sockaddr_info_get() fails, is your system ipv6 by chance?
it probably fails on the first VirtualHost _default_ entry.
could you interactively start with gdb and see where it fails in
apr_sockaddr_info_get? The following script may get it easier for you:
/tmp/debug:
file ~/httpd/prefork/bin/httpd
tbreak main
run -d `pwd`/t -f `pwd`/t/conf/httpd.conf -DONE_PROCESS -DNO_DETATCH -DAPACHE2
# run through all the way to after mod_perl is loaded
b load_module
continue
b apr_sockaddr_info_get
now:
% cd modperl-2.0
% gdb -command=/tmp/debug
p.s. I prefer using ddd which runs gdb underneath, if you use ddd, the syntax
is the same:
% ddd -command=/tmp/debug
__
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 1.99_09dev on AIX4.3.3
ODELL, TODD E (SWBT) wrote: Stas, MUCH Better! ;) I got and tested the CVS an hour ago and it will get through the make test with only one fail: Failed Test Status Wstat Total Fail Failed List of Failed modperl/request_rec_tie_api.t 31 33.33% 1 Great. Can you do: rm t/logs/error_log t/TEST -v modperl/request_rec_tie_api and post the output of the test run and the contents of t/logs/error_log if there is something interesting in it. In the t/logs/error_log I was seeing: exec(): 0509-036 Cannot load program /apache3/bin/httpd because of the following errors: 0509-150 Dependent module /apache3/lib/libaprutil-0.so could not be loaded. 0509-022 Cannot load module /apache3/lib/libaprutil-0.so. 0509-026 System error: The file access permissions do not allow the specified action. But after I changed owner from root to nobody it seemed ok. Then I did the same thing for libapr-0.so. why do you have these problems? what file perms did you have? should be 0755 (-rwxr-xr-x) I think and than he user.group bits won't matter. Unless you have umask settings that forced httpd install to kill the last r-x. What's the output of: % umask normally it's '22' Now the only odd looking thing in t/logs/error_log is: [Thu Mar 27 20:02:48 2003] [error] failed to resolve handler `TestError::syntax' [Thu Mar 27 20:02:48 2003] [error] [client 127.0.0.1] syntax error at /store/modperl-2.0/t/response/TestError/syntax.pm line 17, near \; Compilation failed in require at (eval 98) line 3. These are expected, the test suite tests how well the errors are handled. I'm not sure how can add a banner, saying the following errors are harmless. __ 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 1.99_09dev on AIX4.3.3
ODELL, TODD E (SWBT) wrote: Stas, The output of perl -V:ld -V:cc is: ld='ld' cc='cc' the cc is the IBM Visual Age C (vac.C 4.4.0.3) Thanks. I grabbed the CVS last night after reading msg: 50776 (regarding the TestHooks::init::first) to see if the errors would disappear. When I ran make I remembered there was a small edit for the make to work. In the Makefile and ModPerl-Registry/Makefile there was an undefined FULLPERLRUN. When I changed the FULLPERLRUN to FULLPERL it was fine. Didn't know where that would be in the a Makefile.PL, or elsewhere. Thanks, Todd. That has been fixed in cvs. Please test again. [Wed Mar 26 11:59:18 2003] [error] failed to resolve handler `TestHooks::init::first' [Wed Mar 26 11:59:18 2003] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /store/modperl-2.0/t What happens if you add: PerlModule TestHooks::init somewhere in t/conf/httpd.conf after mod_perl.so is loaded and then run 't/TEST' (not 'make test' as it'll overwrite t/conf/httpd.conf) __ 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: make errors with mod_perl-1.99_08 on aix 4.3.3 5.1
Priest, Darryl - BALTO wrote: Thanks. Compiles ok now, but I'm having trouble with 'make test'. [...] waiting for server to start: .Syntax error on line 12 of /tmp/modperl-2.0/t/conf/httpd.conf: Cannot load /tmp/modperl-2.0/src/modules/perl/mod_perl.so into server: [...] I tried with Apache 2.0.43, got the above messages, so I got the most recent CVS version and still have the problem. Too bad, I guess my solution of using -berok to ignore the linking errors at ld time and resolving everything at run-time doesn't work everywhere, so I probably have to go back to the drawing board and get the ld-time resolving working. However if somebody can give me an access to a fast aix machine, I'll be much more productive. The machine that I have an access to is a way too slow (takes an hour and longer to build mod_perl). Meanwhile, can you please test whether you have the same problem with Apache 2.0.45-tobe, which you can get with: % cvs login (The password is anoncvs, without the quotation marks) % cvs checkout -d httpd-2.0 -r APACHE_2_0_BRANCH httpd-2.0 % ./buildconf % ./configure ... since that's the version I have tested with. Also is do you have this problem on 4.3.3 and 5.1 or only one of these, I couldn't find which one you have referred to in this report. __ 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 1.99_09dev on AIX4.3.3
ODELL, TODD E (SWBT) wrote:
Stas,
I got the CVS tonight and the make was great! A new error on make test
however:
[EMAIL PROTECTED]:/store/modperl-2.0 make test
cd src/modules/perl make -f Makefile.modperl
Target all is up to date.
/usr/local/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 t/TEST
-clean
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -clean
Error in option spec: verbose:1
make: 1254-004 The error code from the last command is 255.
hmm, I've added yesterday a support for
make test TEST_VERBOSE=1 TEST_FILES=...,
this is a problem with Getopt::Long, looks like you have an older version,
which doesn't support this feature (it was added in 2.27). Though don't
upgrade. Let's see if this can be workarounded, since many others have older
version of this module. Try this patch:
Index: Apache-Test/lib/Apache/TestRun.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.103
diff -u -r1.103 TestRun.pm
--- Apache-Test/lib/Apache/TestRun.pm 26 Mar 2003 07:35:33 - 1.103
+++ Apache-Test/lib/Apache/TestRun.pm 27 Mar 2003 06:16:47 -
@@ -160,6 +160,13 @@
local *ARGV = $argv;
my(%opts, %vopts, %conf_opts);
+# a workaround for the unsupported opt:number rule in older
+# Getopt::Long, only for fully spelled out opt -verbose=
+if ($Getopt::Long::VERSION 2.27) {
+@ARGV = grep defined,
+map {/-verbose=(\d)/ ? ($1 ? '-verbose' : undef) : $_ } @ARGV;
+}
+
# permute : optional values can come before the options
# pass_through : all unknown things are to be left in @ARGV
Getopt::Long::Configure(qw(pass_through permute));
__
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 1.99_09dev on AIX4.3.3
ODELL, TODD E (SWBT) wrote: On Mar 24 Stas Bekman Wrote: I've applied some fixes for mod_perl to build on aix. I could only test with aix 5.1 on powerpc. Please test that things work on other configurations. I got 1.99_09dev working on AIX4.3.3/apache 2.0.44 on powerpc_power3. I had trouble with make test, but I'm reviewing the recent messages on that. I decided to see what it would do after make install and it does seem to work. It's shows Apache/2.0.44 (Unix) mod_perl/1.99_09-dev Perl/v5.6.1 PHP/4.3.1. Fantastic! What compiler/loader were you using? on the machine I was testing it was cc_r and ld. What's the output of: % perl -V:ld -V:cc If you provide more details on the 'make test' problems we will try to solve these as well. __ 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: get_server_port (was:Re: run_access_check)
Jie Gao wrote: I have run into another problem, though. I am writing a PerlProcessConnectionHandler based on the example in overview of mod_perl-2.0. It's going to listen on two ports, and I need to know which port is being used in order to set up other things. But I could not get get_server_port work. I have tried: my $s = $r-server; my $port = $s-get_server_port; but got error message: Can't locate object method get_server_port via package Apache::Server at /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx.pm I haven't been able to find relevant documentation. it's a request method, $r-get_server_port You probably want: $s-port __ 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: the deprecation of Apache-request in mp2
Lincoln Stein wrote: I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? That's correct. $r should be explicitly passed. However the CGI-side code doesn't have to specific to mod_perl 2.0. CGI should be able to do that with either version of mod_perl. In this case the user code can be ported to work with both versions of mod_perl. How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. You can still have an accessor function to set $r: use CGI; CGI-r($r); I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Not, under threaded mpm. Since the code should work the same with threaded and non-threaded mpm, it's a problem for any 2.0 code. The problem with Apache-request is that it involves storing and retrieving data from the TLS (thread local storage), which is slow. So while the functionality is there, sites that are looking for high performance will want to pass $r, rather than rely on Apache-request. Of course one can argue, that sites looking for high performance should use Apache::Request (which is not quite there yet, for 2.0). So if this argument is valid and you don't feel like changing the API, that's cool too. May be in the future. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote:
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
That's not what you have sent before ;) But it looks OK in the most recent
version.
A few more comments.
- I have suggested to add a note explaining why we don't rely on
$ENV{MOD_PERL}. I'm sure the reason will be forgotten in the future.
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require mod_perl };
?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] CGI redirects incorrectly handled?
Mark James wrote: Stas Bekman wrote: So can flushing be held off until either (1) blank line is printed, (2) the 8k buffer fills, or (3) send_http_header is called? 1) is relevant only for handler that print headers, rather than set them 2) absolutely not, what if you want to flush data before? 3) send_http_header doesn't exist in Apache2/mod_perl2 I didn't realise that mp2 doesn't use send_http_header. That explains the appearance of wb-r-content_type in the mp2 code. I'm not quite happy yet about the current situation with send_http_header API removal. Currently an explicit call to $r-content_type (only in mod_perl handlers) turns the headers parsing off, if it was on. Which works fine as a replacement for $r-send_http_header. However it's possible that some earlier phase calls $r-content_type and the response phase still wants to *print* its headers, rather than use API to set them. If that's the case, we are in trouble. I'll be soon working on providing the API for PerlOptions and other config options. And while most of these things are read-only, I'm thinking that I might be able to add a read/write accessor for ParseHeaders. So one can turn the parsing on and off, disregarding what was the setting in httpd.conf. I believe that would be the perfect solution, since it'll give developers a total flexibility. So is it true that if headers are sent using the API then no output filtering and transmission occurs until the 8k buffer is either filled or flushed (explcitly or after exit)? That's correct. Though the headers are really sent by the Apache core http output filter, once we send the response body. Only in the case that your handler is configured with: PerlOptions +ParseHeaders *and* it prints headers ala: print Content-type: In all other cases where headers are set via the API, e.g. $r-content_type, $r-headers_out, etc, there is no such a thing as the handler has send an empty line signaling the end of sending headers, because it never sends any headers at all, but uses api to set them. Is +ParseHeaders always indicative of explicit header printing, or can it also be set when using the API? If the former, then yes, if +ParseHeaders is set flushing could be held off until a blank line is seen. See my plan and current situation explanation above. Do we now agree that the event of end of sending headers is possible only in the case explained at the top? Yes, the key I was missing is that mp2 no longer uses send_http_header. Can you just lock out flushing when nothing has been printed and content_type is undefined? (You impliy above that the content_type setting is persistent, so the script would have to undef it if necessary.) Then all the user script has to do is to make sure any Status header is either printed or set via headers_out in the first batch of printing/setting code before flush is called (again). As I suggested earlier, I think the solution is to ignore rflush calls if we expect to parse headers and they weren't parsed yet. However if the buffer overflows, we have not much choice but to send it out. But I think that this will be a satisfactory solution. Also since close($fh) always flushes in mod_cgi, I think you can get rid of the explicit flush for good. Since mod_perl's CLOSE is no-op, it won't cause the flush (at least for now). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote: Sorry for the slow turnaround, but it's an aspect of having 200 new e-mails every day. Here's a new version of CGI.pm 2.92 prerelease. Please give it a try on mod_perl1 and mod_perl2 systems. It passes all tests on linux. Hopefully others will test on other platforms. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
speeding up CGI.pm
While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ 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: shim silence in Apache::MP3
Lincoln Stein wrote: Hi Sean, It sounds like a great idea, but it's not going to happen soon. My first priority is to get Apache::MP3 working with mod_perl 2.0 while maintaining compatibility with mod_perl 1.0.So much has changed between the two versions that I've basically given up on maintaining all my mod_perl scripts until I have a big chunk of free time (unlikely to happen soon, if ever). Looks like a good opportunity for folks who want to get up to speed with mp2 to help CPAN developers port their modules to 2.0. I'm sure Lincoln will appreciate to get a patch that makes Apache::MP3, and his other modules work with mp2. Lincoln, please correct me if I'm wrong ;) On Monday 24 March 2003 08:05 am, Sean M. Burke wrote: Me and Chris Nandor and Joe Johnston were just nattering on about frilly little nicities would like (or have liked) in Apache::MP3. And I just thought of one, hooboy! Namely: maybe an option for inserting 2s of silence between tracks, or maybe just between tracks in different directories. What do you think? Somewhere around here I have some mp3s and oggs of absolute silence, of various runtimes, and even one with a runtime of 4 minutes 33 seconds, of course. __ 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: the deprecation of Apache-request in mp2
Lincoln Stein wrote: How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas 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: speeding up CGI.pm
Gunther Birznieks wrote: Stas Bekman wrote: While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2 If something can be made faster with very little effort, why not doing that? Certainly the degree of performance improvement depends on how heavy the request parsing is, but you get a better speed overall. __ 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 - New Install - Make Test Errors - Resolved
Chris Faust wrote: Thanks for the fixes Stas, I appear to be up and running now.. Just a FYI for reference, I updated the source via CVS and tried it again. That time around I didn't get the TestConfig error but I got pretty much all the same errors that I got on the first (non-cvs) build where it couldn't find init::first, protocol, echo etc. If you want to see the info on that its here. Report http://tagteam.prevare.com/mp2pr1.txt Error Log http://tagteam.prevare.com/mp2pr1log.txt I tried adding them to the init.pm and got the same results. Well, if the problem is not there anymore with the fresh tree, can we consider it solved? The last thing I did was kill the entire source directory, made sure I was just a standard user, downloaded the source via CVS again and then did the build, make and make test as that standard user and then SU'ed to root just for make install and everything went worked like a charm. Now I can see the only thing I ever want to see in my error log: Apache/2.0.44 (Unix) mod_perl/1.99_09-dev Perl/v5.8.0 configured Sweet! ;) -- __ 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] CGI redirects incorrectly handled?
Mark James wrote: Stas Bekman wrote: Mark James wrote: STDOUT is flushed prior to a fork to exec an external binary (rcs). I understand the cause. But I hope that you agree with me that this is an application's problem. If you haven't sent anything to STDOUT yet, don't flush. And if this is not under your control, reopen STDOUT to /dev/null before you call that piece of code, that flushes and then re-tie STDOUT again. (See t/response/TestModperl/request_rec_tie_api.pm) I guess the best way to fix the problem in-application would be to either run nph, or do the /dev/null redirect you suggest. Interestingly, commenting out the pre-fork flush fixes the problem under mod_perl because close in mod_perl seems to be a no-op rather than a flush. If the close is also no problem under mod_cgi then is there any real need for such a pre-fork flush in my script? Since the mod_perl's internal STDOUT buffer isn't mangled if you re-tie it later, and it'll be always flushed at the end of the request, there is no *need* to flush on CLOSE. However in order to be consistent with perl fh close behavior, it probably needs to be changed to flush its buffer. What do you think? I see. But why is there no problem when using mod_cgi? That's an interesting question. mod_cgi is a generic handler, which can run applications written in any language. Therefore it has no clue of what flush is. It simply creates a pipe to the application, and expects the headers headers followed by the data. In your case, when cgi script flushes STDOUT, nothing happens at all, because there is no data to flush. So mod_cgi gets the headers and the data and all is cool When the same code is run under mod_perl, flush generates a special bucket which is sent out to the filters chain, and since no headers are generated yet, they get generated and sent out. Well, even under mod_cgi a program can still fflush or write. Ah, of course! The difference between mod_cgi and mod_perl is that mod_cgi does not activate the filter brigade until it has read all the headers. But in the case of mod_perl, this event is valid only for handlers which print their own headers, rather than using mod_perl API to set them. In the generic case, there is no way to tell whether a handler is going to set more headers or it has done with it. I suppose that we could prevent flushing in the case the handler is configured to parse headers. Does it make sense? Why would a perl handler script want to flush data down the filter chain before it had finished writing all of it? Here is an example: You have a long running process, you want the headers to be sent immediately, but the data won't follow for a while. So you create the headers, do $r-rflush, and later on send the data. OK. So would there be a problem if mod_perl waited for the blank line end of headers, or at least a Status header, before passing the buckets down the line, just like mod_cgi? See above. mod_cgi uses spilling buckets, each of size 8K, to buffer script output, including during the header scan, while mod_perl seems to scan the headers when the first 8K buffer is either filled or flushed. I don't think this is related to the issue in question. Since the problem is what to do on flush. Also we might have a problem if the headers to parse are bigger than the size of the buffer (8k). Do you think someone will ever need to send headers bigger than 8k? __ 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: run_access_check
Jie Gao wrote:
Hi All,
I am getting the following error mesg:
Can't locate object method run_access_checker via package Apache::RequestRec at /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx/.pm
for the section:
sub handler {
my Apache::Connection $c = shift;
my APR::Socket $socket = $c-client_socket;
my $r = Apache::RequestRec-new($c);
$r-location_merge(__PACKAGE__);
my $rc = $r-run_access_checker();
..
Any idea why?
I am using 2.0.44 with mp2 from cvs.
Guessing that you haven't loaded Apache::HookRun.
% lookup run_access_checker
to use method 'run_access_checker' add:
use Apache::HookRun ();
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups
Linked to from:
http://perl.apache.org/docs/2.0/user/compat/compat.html#Code_Porting
and:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Figuring_Out_What_Modules_Need_to_be_Loaded
__
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] CGI redirects incorrectly handled?
The
difference between mod_cgi and mod_perl is that mod_cgi does not
activate the filter brigade until it has read all the headers.
But in the case of mod_perl, this event is valid only for handlers
which print their own headers, rather than using mod_perl API to set
them. In the generic case, there is no way to tell whether a handler
is going to set more headers or it has done with it.
So can flushing be held off until either (1) blank line is printed,
(2) the 8k buffer fills, or (3) send_http_header is called?
1) is relevant only for handler that print headers, rather than set them
2) absolutely not, what if you want to flush data before?
3) send_http_header doesn't exist in Apache2/mod_perl2
I suppose that we could prevent flushing in the case the handler is
configured to parse headers. Does it make sense?
No. Could you explain your reasoning.
Only in the case that your handler is configured with:
PerlOptions +ParseHeaders
*and*
it prints headers ala:
print Content-type:
In all other cases where headers are set via the API, e.g. $r-content_type,
$r-headers_out, etc, there is no such a thing as the handler has send an
empty line signaling the end of sending headers, because it never sends any
headers at all, but uses api to set them.
Are we on the same page now?
mod_cgi uses spilling buckets, each of size 8K, to buffer script output,
including during the header scan, while mod_perl seems to scan the
headers
when the first 8K buffer is either filled or flushed.
I don't think this is related to the issue in question. Since the
problem is what to do on flush.
Also we might have a problem if the headers to parse are bigger than
the size of the buffer (8k). Do you think someone will ever need to
send headers bigger than 8k?
Yes, I mentioned the buffer size in case your objection to my proposal
to wait until end of headers was seen was based on the possiblity of
more than 8k of headers.
Again, the concept of the end of headers exists only in certain cases.
With the current mp2 code, if you decide to
wait for the end of headers before doing cgi parsing and flushing then
the code is assuming that either the headers are less than 8k or that any
Status header is in the first 8k. Otherwise the code would have to
be re-written to use continuous (spilling and merging) buffer buckets
like mod_cgi. It can hold off on flushing indefinitely.
That approach will break this handler:
sub handler {
my $r = shift;
$r-content_type('text/plain');
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
However notice that it doesn't have to set content_type() because some earlier
handler could have done that and that should work as well:
sub handler {
my $r = shift;
$r-rflush; # send something to the client immediately
long_job();
return Apache::OK
}
So as you can see, this handler doesn't tell us when it's done with headers.
OK, you may say that that previous handler should have marked the end of
headers settings, but that would be wrong if the response handler wants to set
other headers as well.
Do we now agree that the event of end of sending headers is possible only in
the case explained at the top?
__
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: make errors with mod_perl-1.99_08 on aix 4.3.3 5.1
I've applied some fixes for mod_perl to build on aix. I could only test with aix 5.1 on powerpc. Please test that things work on other configurations. __ 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 - New Install - Make Test Errors
Chris Faust wrote: Thanks Stas, I tried getting it via CVS and all those other problems went away but I have a new one.. Can't locate Apache/TestConfig.pm This happens right at the end of the make and the module is within @INC. Thanks Chris, this is now fixed in cvs. Please run 'cvs up' and try again. I've missed the problem, since I had an installed Apache/Test. Once I've removed it, the problem was right there. __ 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::Request: analyse output.
Andrew Alakozow wrote:
Hello,
I use Apache::FakeRequest to test perl handlers without firing up Apache.
Testting is supposed to be done by matching output of handlers with some
regexps. But the print method of Apache::Request prints to STDOUT, so to
get output I applied following patch to it:
10c10,17
sub print { shift; CORE::print(@_) }
---
sub print {
my $self = shift;
if (exists $$self{fr_output}) {
$$self{fr_output} .= join ('', @_);
} else { CORE::print(@_) }
}
Now, if fr_output method is defined all output comes there.
my $request = Apache::FakeRequest-new(fr_output = '', ...);
If it's right thing may be this patch should go to CPAN, and if it's not
right, I'll be glad to hear how to do it right.
You can use IO::String for this purpose:
http://perl.apache.org/docs/1.0/guide/porting.html#Redirecting_STDOUT_into_a_Scalar
__
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: Content-Type not working on MSIE
Robert Landrum wrote: On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: Hello, AFAs an aside, if anyone on the list knows of ways to defang this really AFannoying IE behavior, I would be most interested in knowing about it Two (and probably more) ways to do it. This is probably in a FAQ somewhere as it is a common problem. Can someone please summarize the problem and add possible solutions and post it here so we can add it to this document: http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html I think this doc should be renamed to ie_bugs.html ;) __ 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: cvs version make test errors
Jie Gao wrote: Hi All, I got a version from cvs today and make test fails with: special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e Thanks Jie. Your bug report missing the mod_perl and apache information. You should have run t/REPORT to get this as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I can't tell whether you are running a threaded-mpm or a prefork. However, this is not a bug in mod_perl, but a current limitation in one of the testing framework functionalities. Certain tests need to make sure that they hit the same interpreter twice in a row (e.g. to test the closure effect), apparently the current implementation doesn't work well on several platforms, win32 included. If somebody (preferrably on a platform that has this problem) can look at this issue and resolve it, that would be a great help. You can find the code in Apache-Test/lib/Apache/TestRequest.pm and you have several tests that use it (grep for 'same_interp_tie'). The currently used algorithm is very simple: the first request stores the unique id of the perl interpreter in the response headers and on the following requests the client supplies this header. Apache::TestRequest resubmits the request again and again till it hits the same interpreter and only then returns the response to the client. After TRY_TIMES (50) it'll give up and return an error. I'm not sure whether raising of this number to let's say 500 will help to solve the problem. Your help is appreciated. __ 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: cvs version make test errors
Jie Gao wrote: I got a version from cvs today and make test fails with: special_blocks.ok 5/12unable to find interp de76d477-58b9-0310-b94d-dd991812e62e Thanks Jie. Your bug report missing the mod_perl and apache information. You should have run t/REPORT to get this as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I can't tell whether you are running a threaded-mpm or a prefork. However, this is not a bug in mod_perl, but a current limitation in one of the testing framework functionalities. Certain tests need to make sure that they hit the same interpreter twice in a row (e.g. to test the closure effect), apparently the current implementation doesn't work well on several platforms, win32 included. If somebody (preferrably on a platform that has this problem) can look at this issue and resolve it, that would be a great help. You can find the code in Apache-Test/lib/Apache/TestRequest.pm and you have several tests that use it (grep for 'same_interp_tie'). The currently used algorithm is very simple: the first request stores the unique id of the perl interpreter in the response headers and on the following requests the client supplies this header. Apache::TestRequest resubmits the request again and again till it hits the same interpreter and only then returns the response to the client. After TRY_TIMES (50) it'll give up and return an error. I'm not sure whether raising of this number to let's say 500 will help to solve the problem. Your help is appreciated. Guess what, I ran the test again, it passed. :-) I figure this had to do with the load of the machine. Anyway, I was using threaded-mpm with apache 2.0.44. Thanks. However this still needs to be fixed, as random failures aren't good enough. __ 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] CGI redirects incorrectly handled?
Mark James wrote: Mark James wrote: I'm having CGI redirect problems mp2 (cvs). Instead of being redirected to the proper web page, I'm sometimes getting a 302 Moved page containing a link to the correct URL. Damn this was a hard bug to track down. The cause of the problem was my perl code calling flush.pl and flushing STDOUT at a point prior to it printing the response headers. Under mp2, flushing STDOUT calls mpxs_output_flush in xs/Apache/RequestIO/Apache__RequestIO.h, which in turn calls ap_rflush, which triggers creation of the HTTP header, which at this stage, prior to my script printing its 302 header, uses a 200 OK status. So instead of a proper redirect being sent back to the browser, a normal web page with an embedded 302 link is sent. Hmm, why do you flush? The way Apache2 is designed is that the moment you send anything down the filter chain, the headers are generated, because they have to be sent before any data goes out. However mod_perl has an internal buffer and it won't flush the data before it gets full or the code tells it to flush using $r-rflush. If $|==0, then the buffer is not used and the data is flushed on every print. Everything seems to work if the ap_rflush call is removed from mpxs_output_flush, but I don't know if this is the proper way to fix it. No, this is not a proper way to fix it. Otherwise those who want to flush their output won't be able to do so. __ 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] CGI redirects incorrectly handled?
[EMAIL PROTECTED] wrote: The cause of the problem was my perl code calling flush.pl and flushing STDOUT at a point prior to it printing the response headers. Under mp2, flushing STDOUT calls mpxs_output_flush in xs/Apache/RequestIO/Apache__RequestIO.h, which in turn calls ap_rflush, which triggers creation of the HTTP header, which at this stage, prior to my script printing its 302 header, uses a 200 OK status. Meaning no offence to the mp2 developpers, I find this observed behaviour inappropriate - I recently have to develop a reverse-proxy and got bitten by undocumented semantics of this sort every so often, I had to resort to reading the source with pencil paper like the original poster apparently did. I think you are confusing mp2 design with Apache2 design. This is how Apache2 works, the main reason I believe to accomodate the filtering mechanism. As for undocumented behavior, you are welcome to submit documentation patches or wait till someone will write them. What is the architectural justification for not choosing one of those two behaviours about header output, and erring on the middle side: * headers are out-of-band, and the first call to print() prepends whatever headers were set using the appropriate API (e.g. print_header() should have no effect afterwards, or maybe should set HTTP/1.1 trailers); That's exactly how it works. The first print/puts/printf/rflush causes the headers to be sent (assuming that STDOUT is unbuffered), using whatever headers were set so far. Do I miss something here? This is 1:1 mapping to Apache behavior. The only difference is the mod_perl internal STDOUT buffer used for buffered STDOUT. * headers are regular flow, and Apache / mp2 never tries to add its own ones (almost impossible to ensure under Apache / mp1). Thanks for any insight on this topic - maybe there is a FAQ somewhere about MP2 architecture ? There are Doug's architecture notes online, I did some changes to them to bring things to the current state of things. They are certainly could have some more work. Patches are welcome. __ 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] CGI redirects incorrectly handled?
Mark James wrote: Stas Bekman wrote: Mark James wrote: The cause of the problem was my perl code calling flush.pl and flushing STDOUT at a point prior to it printing the response headers. Hmm, why do you flush? STDOUT is flushed prior to a fork to exec an external binary (rcs). The child is closing STDOUT and then redirecting it into a pipe to the parent. I didn't write this part of the code, but the comment on the flushing is: # flush now, lest data in a buffer get flushed on close() in every stinking # child process. The code for the forking is: bulletproof fork from camel book, 2ed, page 167 If necessary I can propose a patch to this perl package to make the flushing conditional on not running under mod_perl. I understand the cause. But I hope that you agree with me that this is an application's problem. If you haven't sent anything to STDOUT yet, don't flush. And if this is not under your control, reopen STDOUT to /dev/null before you call that piece of code, that flushes and then re-tie STDOUT again. (See t/response/TestModperl/request_rec_tie_api.pm) Technically it's possible to add a flag in mod_perl 2.0 to ignore any flush attempts, if no data data was printed yet. However, this could become an undesirable behavior for someone who wants to send a flush before any data is sent. In your case, you can work around the problem, in the case of a person who wants the other behavior, there is no workaround. So I suggest that we keep the mp behavior generic and not create special cases we may regret about later on. The way Apache2 is designed is that the moment you send anything down the filter chain, the headers are generated, because they have to be sent before any data goes out. However mod_perl has an internal buffer and it won't flush the data before it gets full or the code tells it to flush using $r-rflush. If $|==0, then the buffer is not used and the data is flushed on every print. I see. But why is there no problem when using mod_cgi? That's an interesting question. mod_cgi is a generic handler, which can run applications written in any language. Therefore it has no clue of what flush is. It simply creates a pipe to the application, and expects the headers headers followed by the data. In your case, when cgi script flushes STDOUT, nothing happens at all, because there is no data to flush. So mod_cgi gets the headers and the data and all is cool. When the same code is run under mod_perl, flush generates a special bucket which is sent out to the filters chain, and since no headers are generated yet, they get generated and sent out. As I wrote this, I'm actually starting to think that it's Apache who should ignore the flush bucket if it had seen no other data so far, and not generate any headers till it actually sees the real data. Everything seems to work if the ap_rflush call is removed from mpxs_output_flush, but I don't know if this is the proper way to fix it. No, this is not a proper way to fix it. Otherwise those who want to flush their output won't be able to do so. Why would a perl handler script want to flush data down the filter chain before it had finished writing all of it? Here is an example: You have a long running process, you want the headers to be sent immediately, but the data won't follow for a while. So you create the headers, do $r-rflush, and later on send the data. __ 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] CGI redirects incorrectly handled?
Stas Bekman wrote: As I wrote this, I'm actually starting to think that it's Apache who should ignore the flush bucket if it had seen no other data so far, and not generate any headers till it actually sees the real data. And I went to produce a patch in http_filter, I figured that that would be wrong for the same reason, mod_perl shouldn't handle that as a special case, since that behavior might be a desired one. Another workaround for your problem could be a custom output filter, that yanks any bucket brigades including only the flush bucket, if it had not seen any real data buckets yet. __ 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: Using a Startup.pl
Thomas Klausner wrote: Hi! On Tue, Mar 18, 2003 at 01:39:41PM -0500, Chris Faust wrote: I'm running mod_perl 2 on RedHat with Apache 2.0.44 and I'm using NamedBased Virtual Hosting in apache (so I have a number of virtual hosts and apache directs properly based on hostname). I use a startup.pl to load up common things like DBI, CGI, HTML::Template etc.. Should I have just a single startup.pl and will that work with all virtual hosts? Or should I have a startup.pl per virtual host. AFAIK, and with mod_perl 1.x, having multiple startup.pl's makes no sense as they all get executed during server startup and in the main namespace. That's correct only for mod_perl 1.0. For mod_perl 2.0 this depends on whether 'PerlOptions +Parent' is set or not. If it is each vhost can have their own startup.pl (only that vhost will ever execute/see the code that run from it). It's documented here: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ (though as someone reported PerlOptions +Parent doesn't work inside the Location container, I haven't had a chance to work on it yet.) However this is all new code and not very tested yet, so I won't be surprised if there are problems with it. If you have problems report them as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems __ 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: Using a Startup.pl
Chris Faust wrote: I'm running mod_perl 2 on RedHat with Apache 2.0.44 and I'm using NamedBased Virtual Hosting in apache (so I have a number of virtual hosts and apache directs properly based on hostname). also make sure to upgrade your mod_perl 2 to the latest stable version 1.99_08 or even better the cvs one. The one coming with RH is too old. Save yourself troubles. http://perl.apache.org/download/index.html __ 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] adding SERVER_ROOT and SERVER_ROOT/lib/perl to @INC
Nick Tonkin wrote:
On Mon, 17 Mar 2003, Perrin Harkins wrote:
Goehring, Chuck Mr., RCI - San Diego wrote:
Where do you put your .pm files for application-specific code?
Under mod_perl 1, I just put them in SERVER_ROOT/lib/perl, which is
automatically added to @INC by mod_perl. Can someone confirm if this
still works for mp2?
I do not believe so.
Though it is easy to add. See the patch below.
The question is, do we want to have this feature in mp2? Does it really save
someone a trouble of creating a startup file? Also, In 2.0 you don't have to
create a startup file for that, you can simply say:
PerlSwitches -I/home/httpd -I/home/httpd/lib/perl
Admittedly you will have to hardcode the document root in this case, but you
do that anyways in httpd.conf when you specify it.
Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.157
diff -u -r1.157 mod_perl.c
--- src/modules/perl/mod_perl.c 17 Mar 2003 02:15:09 - 1.157
+++ src/modules/perl/mod_perl.c 18 Mar 2003 22:55:08 -
@@ -190,6 +190,11 @@
);
#endif
+av_push(GvAV(PL_incgv),
+newSVpv(ap_server_root_relative(p, ), 0));
+av_push(GvAV(PL_incgv),
+newSVpv(ap_server_root_relative(p, lib/perl), 0));
+
if (!modperl_config_apply_PerlRequire(s, scfg, perl, p)) {
exit(1);
}
__
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: required files not in a namespace?
Justin Luster wrote: Are required files in a namespace under Apache::Registry in Mod_Perl? I have just done a simple test that seems to show that they are not in a namespace. In the documentation (http://perl.apache.org/docs/1.0/guide/intro.html#Apache__Registry) it says that the initial script is stored under a unique key to prevent script name collisions. This seems to work for the main script that you call but not for the required files that that script uses. See: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs __ 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] adding SERVER_ROOT and SERVER_ROOT/lib/perl to @INC
Perrin Harkins wrote: Stas Bekman wrote: The question is, do we want to have this feature in mp2? I thought it was cool to have it automatically add a path relative to the server root, because it makes it feel more like you are writing real Apache modules, and not just CGI scripts. It's just a warm fuzzy thing really. I have no problem with dropping that feature and adding the path myself in startup.pl or httpd.conf. I'm +0 on adding this feature. While I have never used it myself, I see no harm in keeping back-compatibility with 1.0. Unless someone has a reason for not having it I'll commit the patch I've posted earlier. __ 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] Using DBI instead of Apache::DBI
[please keep the threads on the list unless requested otherwise]
Georg Botorog wrote:
Thanks. But I still have not understood how I avoid to include
Apache::DBI in the current version of Apache (2). In mp1, there was an
explicit inclusion statement in httpd.conf, which I could leave out. I
have found nothing of the kind in mp2. Still, Apache::DBI is loaded.
Maybe I have not expressed clearly: I do not want to unimport an
included module, I simply do not want to include a special module,
Apache::DBI, at all in a certain instance of Apache.
What you are saying is that you don't load Apache::DBI, but something else
does, right?
Install this override at the very beginning of your startup.pl and watch the
logs to see who loads Apache::DBI.
*CORE::GLOBAL::require = sub {
warn require $_[0]\n;
CORE::require(@_)
};
This should work with 5.6.x, not sure about earlier perl versions.
-Original Message-
From: Stas Bekman [SMTP:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:55 PM
To: Georg Botorog
Cc: [EMAIL PROTECTED]
Subject:Re: [mp2] Using DBI instead of Apache::DBI
Georg Botorog wrote:
Hello,
In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user
connections (DBI) on the same machine required running two Apache
instances, one with Apache::DBI and the other without it.
Has anything about that changed in mod_perl2?
Moreover, how does Apache2 know it has to load Apache::DBI? There is
no PerlModule Apache::DBI statement in my httpd.conf (as it was
under mp1), neither a use Apache::DBI in startup.pl or in any
other
module. Or, to put it the other way around: how can I avoid
including
Apache::DBI (in the DBI-only instance)?
As you said Apache::DBI is either on or off and it will work just the
same
under mp2 as it does under mp1.
However in the near future DBI is going to support pooling internally,
which
will take the benefit of threads if available.
And I think it could be made more flexible than Apache::DBI, i.e. too
be more
than just on or off. I think Apache::DBI can do the same. What we
really need
is some sort of pragma where you can control Apache::DBI. e.g. let's
say that
once you load Apache::DBI it turns the pooling on globally. But than
in your
script you should be able to say (you can't do it just yet):
no Apache::DBI; # which calls Apache::DBI::unimport
$dbh = DBI-connect(...)
and the unimport will restore the default DBI behavior for the scope
of that
pragma (e.g. handler) and restores to the previous behavior on the
scope exit.
Similar to how the warnings pragma works.
It's be nice to have a generic pragma for turning any functionality on
and off
(do we have one already?). e.g. let's call it 'override':
use override 'Apache::DBI';
# Apache::DBI overrides DBI here
no override 'Apache::DBI';
# the previous functionality is restored (e.g. back to DBI)
__
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
--
__
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: Doc clarifications requested
Perrin Harkins wrote:
Stas Bekman wrote:
Ron Savage wrote:
I see this item:
if one wishes to simply read POST data, there is the more modern
{setup,should,get}_client_block API, and even more modern filter API.
Along with continued support for read(STDIN, ...) and $r-read($buf,
$r-headers_in-{'content-length'})
I feel the sentence stating with 'Along' should not belong under that
dot point.
Consider it as a footnote? Could put () around it I guess.
Also, it's not a complete sentence, so what does it mean?
what's not complete? Please be more explicit.
He means that starting the sentence with Along with is not correct
English usage. Try changing Along with to There is also.
ah, of course, there should have been a comma, instead of a period.
there is the more modern
{setup,should,get}_client_block API, and even more modern filter API,
along with continued support for read(STDIN, ...) and $r-read($buf,
$r-headers_in-{'content-length'}).
Thanks Perrin.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if
people could test it on both mod_perl 1 and mod_perl 2, as well as under
normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test suites
aren't exhaustively cover CGI.pm's functionality. So we really need your help
guys to give it a good test in the real apps.
In case anyone wonders why I fiddled with the check for the presence of
modperl, this is because some people write scripts that shell out to
command-line scripts that invoke CGI.pm in order to generate HTML (don't ask
me why). Without the additional checking, CGI.pm sees the MODPERL
environment variable, tries to load mod_perl outside the Apache environment,
and summarily crashes.
Ahm, I'm not quite sure that this does what you say it should:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
because if it's not defined, it'll fall through to the else block, assuming
that the external script is running under mp1. Shouldn't it be:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
if ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
}
also it's probably a good idea to add a note, why this check is done, so not
to forget in the future and optimize it away ;)
I still haven't heard any response as to why I should move to MP2! I wasn't
just being cranky, I'm curious.
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on win32, serialization)
and there is a whole bunch of new functionality available, which will be too
long to list here and partially described on the website.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Stas Bekman wrote: Lincoln Stein wrote: Please find enclosed a beta version of CGI.pm 2.92. I would appreciate it if people could test it on both mod_perl 1 and mod_perl 2, as well as under normal CGI scripts too ;-) Thanks Lincoln. 'make test' passes with mp1 and mp2 Ah, no it doesn't pass 1.0 tests. I was too quick to post. I've replaced send_cgi_header with direct setting of $r-headers_out without doing the special handling for several headers. I'll revert it to use send_cgi_header. I thought we could get rid of this function, but it's better to keep it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: CGI.pm and friends port to mp2
Stas Bekman wrote:
Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would
appreciate it if people could test it on both mod_perl 1 and mod_perl
2, as well as under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2
Ah, no it doesn't pass 1.0 tests. I was too quick to post. I've replaced
send_cgi_header with direct setting of $r-headers_out without doing the
special handling for several headers. I'll revert it to use
send_cgi_header. I thought we could get rid of this function, but it's
better to keep it.
Here is a new patch. I've attached it as well, in case it gets mangled.
I've also incorporated the defined() fix that I've commented on earlier.
Please check if that's what you meant.
--- /tmp/CGI.pm-2.92/CGI.pm 2003-03-14 06:47:03.0 +1100
+++ /home/stas/perl/blead-ithread/lib/5.9.0/CGI.pm 2003-03-14
10:47:05.0 +1100
@@ -173,14 +173,18 @@
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
require mod_perl;
- if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
-$MOD_PERL = 2;
-require Apache::RequestRec;
-require Apache::RequestUtil;
-require APR::Pool;
- } else {
-$MOD_PERL = 1;
-require Apache;
+ # mod_perl handlers may run system() on scripts using CGI.pm
+ # - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
+ if (defined $mod_perl::VERSION) {
+if ($mod_perl::VERSION = 1.99) {
+ $MOD_PERL = 2;
+ require Apache::RequestRec;
+ require Apache::RequestUtil;
+ require APR::Pool;
+} else {
+ $MOD_PERL = 1;
+ require Apache;
+}
}
}
@@ -1320,21 +1324,12 @@
push(@header,map {ucfirst $_} @other);
push(@header,Content-Type: $type) if $type ne '';
- if ($MOD_PERL and not $nph) {
- my $r = Apache-request;
- for (@header) {
- my($k, $v) = split /:\s+/, $_, 2;
- if ($k eq 'Content-Type') {
- $r-content_type($v);
- }
- else {
- $r-headers_out-{$k} = $v;
- }
- }
-$r-send_http_header() if $MOD_PERL == 1;
- return '';
- }
-return join($CRLF,@header).${CRLF}${CRLF};
+my $header = join($CRLF,@header).${CRLF}${CRLF};
+if ($MOD_PERL and not $nph) {
+Apache-request-send_cgi_header($header);
+return '';
+}
+return $header;
}
END_OF_FUNC
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
diff
Description: application/java-vm
the deprecation of Apache-request in mp2
One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_request_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas 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: h2xs
Blayne Bayer wrote: I might be posting this to the wrong group Have you tried searching for the right forum before posting here? In the future check this document first: http://perl.apache.org/docs/offsite/other.html Your XS questions probably belong here: http://lists.perl.org/showlist.cgi?name=perl-xs __ 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: Dual Processors Mod Perl
Jim Morrison [Mailing-Lists] wrote: [...] I'm just wondering how Linux (RedHat 7.2) deals with dual processors, [...] Does linux just take care of 2 proccessors or does the code have to be compatable? If you are using a non threaded mod_perl, which is the case with - mod_perl 1.0 - mod_perl w/ prefork mpm and you don't spawn your own threads, which you can. then your code will work all the same. The only difference is that if your code had any race conditions, chances are higher that you will hit them on a machine with more than one CPU. On race conditions see: http://perl.apache.org/docs/1.0/guide/debug.html#Critical_Section If you use mod_perl 2.0 w/ threaded mpm, your code and all libs that you use have to be re-entrant and thread-safe, no matter whether you are using a single- or multi-processor machine. Again if you code does have thread related problems, you are more likely to see them on an SMP machine. __ 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: Compiling Apache::Scoreboard
[EMAIL PROTECTED] wrote: Hi, I'm getting a bizarre compile error while trying to build Apache::Scoreboard 0.10 on a Mandrake Linux 9.0 system. Here's a snippet of make output, from the first gcc command that failed to just the first few errors it generates: gcc -c -I../ -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/include -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/regex -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/os/unix -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586 -ffast-math -fno-strength-reduce -DVERSION=\0.04\ -DXS_VERSION=\0.04\ -fpic -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -DPERL_THREADS DummyScoreboard.c In file included from DummyScoreboard.xs:14: /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:261: parse error before '*' token /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:261: warning: data definition has no type or storage class /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:264: parse error before '*' token /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/include/modules/perl/mod_perl.h:264: warning: data definition has no type or storage class I think this has to do with the ordering of including apache headers. This was fixed in the cvs version of mod_perl 1.0. Can you please try to rebuild mod_perl using the cvs version and then give another chance to Apache::Scoreboard? http://perl.apache.org/download/source.html#Development_Source_Distribution __ 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 + GnuPG
Gareth Palmer wrote: I'm getting a strange error while trying to using the GnuPG module while running under mod_perl (everything works fine when executing from a shell) The message is: Can't locate object method OPEN via package Apache::RequestRec (perhaps you forgot to load Apache::RequestRec?) at /usr/lib/perl5/site_perl/5.6.3/GnuPG.pm line 252 mod_perl 1.99_08 OPEN was added after 1.99_08. Please build the cvs version of mod_perl 2.0: http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution __ 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: PerlCleanupHandler firing too early?
Trey Hyde wrote:
My PerlCleanupHandler seems to be firing before the content phase has
finished processing the page.
The handler pretty much looks like
sub handler {
my ($r) = @_;
undef $Foo::bar;
undef $Foo::baz;
return OK;
}
It's being invoked in a virtual host apache conf segment with
PerlCleanupHandler Apache::CleanupFoo
If I don't comment out the PerlCleanupHandler line pieces of the
application that rely on any variable that I undef in the Cleanup phase
will crash.
In the error log it doesn't _LOOK_ like the handler is being called
early. The log yields exactly what I would expect it to.
PID 1000 REWRITE CALLED initial: 1 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 1
PID 1000 AUTHENTICATION CALLED
BUNCH OF PERL ERRORS GO HERE (can't call method foo on undefined value
and the like)
PID 1000 REWRITE CALLED initial:0 main: 1 (rewriting
/cgi-bin/error/error.pl)
PID 1000 LOGGER CALLED (uri: error.pl)
PID 1000 CLEANUP CALLED (uri: mod_perl app)
I'm running on Apache/1.3.27 (Unix) mod_perl/1.26 w/ embperl 1.3.6.
Does anyone have an idea of what is going on here (or what I'm doing
wrong here?). Am I right in thinking that the CleanupHandler isn't
supposed to have any effect on the code _running_ in the current or
subsequent processes? In summary, leave Cleanup handler in everything
that I undef in the cleanup handler gets undef'ed in the middle of
running the code, if I removed the CleanupHandler the app works as
intended.
In the current request the CleanupHandler happens the last. You can visually
see that using Apache::ShowRequest
http://search.cpan.org/author/DOUGM/Apache-Module-0.11/lib/Apache/ShowRequest.pm
However you don't show the code that you have the problem with, so certainly
we have no clue why does it fail. If your cleanup handler affects global
variable in the package, certainly you may have an impact on the subsequent
requests running in the same process.
If you still have this problem, reduce the problematic code to the very
minimum (2-3 lines of code?), so that the problem can be still reproduced and
post it 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
Re: What does SetHandler do unexpectedly?
Frank Maas wrote: Hi, Well, by now you must know that I am working on something... and I keep stumbling on things I seem not to understand and not to be able to find in the docs / books. See this example: Location / # SetHandler perl-script PerlHeaderparserHandler MyClass-first PerlAuthenHandler MyAuthen PerlFixupHandler MyClass-init # PerlHandler MyClass-handler PerlCleanupHandler MyClass-last /Location I have stripped almost all functionality and just let the subroutines print. With this setup and a 'get http://mysite/dir/file' I see: -- first: got /dir/file authen: called for /dir/file init: called for /dir/file [error] ... /dir/file not found -- last: finished /dir/file No strange things, what I would expect. But now I remove the comments and see what happens: -- first: got /dir/file authen: called for /dir/file init: called for /dir/file authen: called for /file init: called for /file handler: called for /dir/file [error] ... /dir/file not found -- last: finished /dir/file What strike me are the two lines for /file. Why is this happening? I did not ask for it, at least not deliberately. Is this something that is related to a Handler (check one level below the uri)? Hope you can help me here (and on the other subjects...) Try to see if this helps: http://search.cpan.org/author/DOUGM/Apache-Module-0.11/lib/Apache/ShowRequest.pm We certainly can't guess what other handlers and configurations you may have that affect the process. it looks like something runs a sub-request, you may want to add to your authen handler an extra printout checking if it's inside a subrequest: warn $r-is_initial_req ? main req\n : sub req\n; it seems like your transhandler is returning DECLINED and Apache's default handler is running, trying to find /dir/file, and then trying /file. Or you may have something else. It's of no help to guess. __ 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: Doc clarifications requested
Ron Savage wrote:
Folks
(1)
On this page:
http://perl.apache.org/docs/2.0/user/compat/compat.html
Under this heading:
$r-args in an Array Context
Why not using a direct pointer ;)
http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_args__in_an_Array_Context
I see this item:
if one wishes to simply read POST data, there is the more modern
{setup,should,get}_client_block API, and even more modern filter API.
Along with continued support for read(STDIN, ...) and $r-read($buf,
$r-headers_in-{'content-length'})
I feel the sentence stating with 'Along' should not belong under that
dot point.
Consider it as a footnote? Could put () around it I guess.
Also, it's not a complete sentence, so what does it mean?
what's not complete? Please be more explicit.
Some of the entries in this document do need expansion and clarification. So
if something is not clear, let's figure out how to make it clear and fix it.
It'd immensely helpful if those who use mod_perl 2.0 and learn the ropes help
to improve the docs, and release our fingers from writing docs and let us
write some code ;)
(2)
Same page.
http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_is_main_
I see this text:
$r -is_main is not part of the mod_perl 2.0 API. Use !$r-main
instead.
(a) Is the '!' correct?
Yes. See:
http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_is_main
(b) Should it refer to is_inital_req
s/is_inital_req/is_initial_req/
why? $r-main works on the request object, it doesn't indicate the kind of
request. So you can be in sub-request, and request $r from the initial_req.
If you were using $r-is_main to figure out whether it's is_initial_req, you
were probably doing a wrong thing, no? So I think in this sense these two
functions are unrelated. However, read on.
(c) Would it be possible to add a reference for is_initial_req?
Let's try to keep this document is simple as possible. Think of it as a
temporary helper map to find out what happened to some mp1 method that is not
there anymore, or working differently. Remember that eventually, people won't
need to refer to the compat doc. Since they will all write in mp2 API.
I suggest the following solution:
We add a pointer to the Apache::RequestRec manpage (which should document
is_initial_req()) from that entry. In the Apache::RequestRec manpage we add a
xref to main() (Apache::RequestRec) and the other way around.
Sounds good?
BTW, did I mention that patches are *very* welcome? :)
Thank you.
__
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: Doc clarifications requested
(c) Would it be possible to add a reference for is_initial_req? Let's try to keep this document is simple as possible. Think of it as a temporary helper map to find out what happened to some mp1 method that is not there anymore, or working differently. Remember that eventually, people won't need to refer to the compat doc. Since they will all write in mp2 API. I suggest the following solution: We add a pointer to the Apache::RequestRec manpage (which should document is_initial_req()) from that entry. In the Apache::RequestRec manpage we add a xref to main() (Apache::RequestRec) and the other way around. sorry, should have been Apache::RequestUtil Please check an updated entry: http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_is_main_ __ 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] Using DBI instead of Apache::DBI
Georg Botorog wrote: Hello, In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user connections (DBI) on the same machine required running two Apache instances, one with Apache::DBI and the other without it. Has anything about that changed in mod_perl2? Moreover, how does Apache2 know it has to load Apache::DBI? There is no PerlModule Apache::DBI statement in my httpd.conf (as it was under mp1), neither a use Apache::DBI in startup.pl or in any other module. Or, to put it the other way around: how can I avoid including Apache::DBI (in the DBI-only instance)? As you said Apache::DBI is either on or off and it will work just the same under mp2 as it does under mp1. However in the near future DBI is going to support pooling internally, which will take the benefit of threads if available. And I think it could be made more flexible than Apache::DBI, i.e. too be more than just on or off. I think Apache::DBI can do the same. What we really need is some sort of pragma where you can control Apache::DBI. e.g. let's say that once you load Apache::DBI it turns the pooling on globally. But than in your script you should be able to say (you can't do it just yet): no Apache::DBI; # which calls Apache::DBI::unimport $dbh = DBI-connect(...) and the unimport will restore the default DBI behavior for the scope of that pragma (e.g. handler) and restores to the previous behavior on the scope exit. Similar to how the warnings pragma works. It's be nice to have a generic pragma for turning any functionality on and off (do we have one already?). e.g. let's call it 'override': use override 'Apache::DBI'; # Apache::DBI overrides DBI here no override 'Apache::DBI'; # the previous functionality is restored (e.g. back to DBI) __ 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: Need Help With Apache::Filter (mod 1.x)
David Culp wrote: Any Examples of Apache::Filter would be greatly appreciated. http://www.cpan.org/authors/id/G/GE/GEOFF/Apache-Clean-0.05.tar.gz p.s. Apache-Clean-2.x is for mp2. __ 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] Documentation
Nick Tonkin wrote: On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote: Hi - I'm getting frustrated. I'm trying to parse the incoming uri (url) in mod_perl 2, and I can't seem to be able to find documentation. For example, Nick gave me the following snippet of code last week: [...] Have you tried the pretty good (tm) search engine on the mod_perl site itself? Note that you can restrict your search to the 2.0 docs. For example, searching for `APR::URI-parse' gave me one result: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache__URI_E_gt_parse__ruri___ which has exactly what I need. Now of course it also refers me to the man page for APR::URI, which does not (apparently) exist. Well, I've added pointers to the manpages while writing the compat docs, so once they get added I don't have to go back and look where I want it to be added ;) Hey, the build system is smart enough to check whether the manpage actually exist and link to it. So once it's added the plain text will become a link. But I'm sure it doesn't help you *now*. I think it may be harder for you, Beau, since you started working with mod_perl with this beta 2.0 version, and don't have a grounding in mod_perl from v. 1.0. The docs work best when you know what you want to do and how to do it in mp1, and can then find the equivalent for mp2. Currently, your best source of information: 1) for APIs that haven't changed since mp1 (or have remained quite similar) is to look at perl.apache.org/docs/1.0/ (as Nick has pointer out) 2) for APIs that are new to mp2 (and for mp1 APIs) look at the tests that exercise them. It's the best place to see how things work, because you can actually run them. See modperl-2.0/t/*/*/*.pm (modperl-2.0/t/*.t are driving the tests). Now re: docs Documentation is roughly split into API manpages and user guide (plus core developer docs). 1) The API manpages are just that: the manpage. Lyle and Gerald were working on a system to automatically generate the API manpages from apache docs (and after that we will need to massage them to bring them to the perl world). I haven't heard from the folks for a while. Lyle and Gerald, can you please update us if there was any advancement in the project? 2) The user guide part is the actual tutorial-like docs, where the API is devided not by class/method but by functionality. I've started working on it and now you have tutorials for writing filters, protocol modules, HTTP handlers, but only the basic things. Now we need to produce more tutorial-like sections covering the various tasks at hand (e.g. what Beau needed: parsing uris). Think of the eagle book and the cookbook. We need something similar. And also don't forget that we have a bunch of mp1 docs that can be ported to mp2 with a little effort. So if you want the docs, you need to help to produce them. One you figure out how to parse uri, look at the mentioned books and mp1 docs and produce a section for others to re-use. Somebody else will figure out how to use pools and submit a section on how to use these. Etc.. If everybody were to contribute a little, we would have a great tutorial pretty soon. And the frustration factor will get much lower. People will again start grumbling that there are too many docs for their liking, as it is situation with mp1 docs. But I prefer the latter ;) Looking forward for your docs submission. __ 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::sandwich
Nick Tonkin wrote: On Mon, 10 Mar 2003, Brent Baude wrote: I recently uprgaded from a pre-RedHat8 system to RedHat 8. I used the Apache::Sandwich module to specify a directory and footer filename in the directives to allow me to include footer files dynamically (without having to specify an include statement in each file served). Is there something like this module or an alternative for Apache 2 versions? mod_perl 2 supports output filtering, which could provide a streamlined way of doing what Apache::Filter does fairly trivially AFAIK. But you'd have to read up on filters and implement it yourself. Another option would be for you to port Apache::Filter to run under mp2. Then your code as well as anyone else's who uses that module would run unchanged under mp2. That would be a Good Thing and you'd be a mod_perl hero. People on this list would help if you got stuck, and the documentation for porting is getting quite extensive. This doc: http://perl.apache.org/docs/2.0/devel/porting/porting.html is what you want. What Nick said and make sure to also read: http://perl.apache.org/docs/2.0/user/compat/compat.html ;) __ 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: Porting Orphans : (was: apache::sandwich)
[EMAIL PROTECTED] wrote: This brings up a good point, is there a list of 'ModPerl Orphans' anywhere? For the most part I would imagine that a modules author/maintainer will manage the transition to mp2 but there must be a ton of modules that are Orphans with little hope of making it over unless some kind developer makes it happen. It would be pretty great if there was a list and people could start taking responsibility for the tasks to avoid duplicate work as well as to guide folks who have time to contribute and are not sure where to start. Lame suggestion most likely. I was just thinking 'I would like to try to port something but where to start' If there is interest in this I can put up a page for this sort of thing and send email out to all of the existing authors, hunting for orphans to post. It's a good idea to compile a list of modules that need to get ported, discarding those that aren't needed in mp2 (e.g. Apache::Filter and FilterChain are definitely to stay in the mp1 world I believe). However there is a problem with porting modules that include XS code, since the replacement for Apache::src hasn't been completed yet. Pure perl modules porting should be fine. FWIW, I've ported Apache::Peek and Apache::Scoreboard to 2.0, but I can't release them yet as they need a support from mod_perl-2.0 (because of Apache::src/xs stuff), which wasn't committed yet. We are hoping to deliver a much better Makefile.PL support (including things like installing into Apache2/ and automatic configuration of the MM attributes for compilation) __ 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: Newbie help with mod-perl 2.0
Svein E. Seldal wrote:
Hello,
I'm running: Apache/2.0.44 (Win32) mod_perl/1.99_09-dev Perl/v5.8.0
good choice ;)
I'm toying around with mod_perl handlers. And I've written this silly
little app attached below which works partly. My problem is simple:
- I need to get the querystring (and possibly the xform contents as
well). And I would like to receive it parsed (in a hash). But when I use
$r-args() I get the whole lot in a single variable. And I get hints
from doc's lying around that args() is depreciated. How can I get the
querystring anno mod_perl 2.0? Do I have to parse it myself?
$r-args in the *list* context is deprecated. See:
http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_args__in_an_Array_Context
For now you can copy the pure-perl implementation from Apache/compat.pm. Later
when Apache::Request is ported you will be able to use the faster C implementation
- The script below leaves a message in apache's error log:
Can't locate object method request via package Apache::RequestRec at
D:/Prosjekt/designs/gear/gear2/Test/Test.pm line 49.
I would guess that I lack a use Apache::SomeThing;, but I cant figure
it out. (Mainly because I cant find references to it in any documentation.)
Because you haven't read this:
http://perl.apache.org/docs/2.0/user/compat/compat.html#Code_Porting
which at the end links you to:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html
Also see:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Porting_mod_perl_1_0_Modules_to_Work_with_mod_perl_2_0_
package Test::Test;
use strict;
use warnings;
use Apache::Reload;
use Apache::RequestRec;
use Apache::RequestIO;
use Apache::Const -compile = qw(OK);
sub handler {
my $r = shift;
$r-content_type('text/plain');
print mod_perl 2.0 rocks!\n;
my $path_info = $r-path_info();
print path_info: $path_info\n;
my $method = $r-method();
print method: $method\n;
my %a = $r-args();
my @b = %a;
print Args . @b . : @b\n;
my $content = $r-request();
/home/stas lookup request
to use method 'request' add:
use Apache::RequestUtil ();
see:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
CGI.pm and friends port to mp2
Hi Lincoln,
I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
myself. This isn't likely in the near future, since I'm very happy indeed
with MP1/Apache1.
I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more
Apache/compat.pm). I did some basic testing, however it'd be nice if people
were to test this patch and confirm that I didn't break anything that did work
before. So that Lincoln doesn't have to figure out how to test it.
I've attached the diff against 2.91 distro.
One more thing, Lincoln, why CGI.pm does:
$| = 1;
without localizing the change, when running under mod_perl? This has a
potentially bad effect on the rest of the modules running under the same
server, since now every print() will flush the data. Can this setting be
localized (this will probably require to move the unbuffering where it's
relevant, rather than globally)?
Thanks.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--- CGI.pm.orig 2003-03-09 18:29:48.0 +1100
+++ CGI.pm 2003-03-11 12:30:23.0 +1100
@@ -36,6 +36,8 @@
my @SAVED_SYMBOLS;
+$MOD_PERL = 0; # no mod_perl by default
+
# Here are some globals that you might want to adjust
sub initialize_globals {
# Set this to 1 to enable copious autoloader debugging messages
@@ -159,16 +161,17 @@
$IIS++ if defined($ENV{'SERVER_SOFTWARE'}) $ENV{'SERVER_SOFTWARE'}=~/IIS/;
# Turn on special checking for Doug MacEachern's modperl
-if (exists $ENV{'GATEWAY_INTERFACE'}
-
-($MOD_PERL = $ENV{'GATEWAY_INTERFACE'} =~ /^CGI-Perl\//))
- {
+if (exists $ENV{MOD_PERL}) {
$| = 1;
require mod_perl;
if ($mod_perl::VERSION = 1.99) {
- require Apache::compat;
+$MOD_PERL = 2;
+require Apache::RequestRec;
+require Apache::RequestUtil;
+require APR::Pool;
} else {
- require Apache;
+$MOD_PERL = 1;
+require Apache;
}
}
@@ -278,9 +281,15 @@
my($class,$initializer) = @_;
my $self = {};
bless $self,ref $class || $class || $DefaultClass;
-if ($MOD_PERL defined Apache-request) {
- Apache-request-register_cleanup(\CGI::_reset_globals);
- undef $NPH;
+if ($MOD_PERL) {
+my $r = Apache-request;
+if ($MOD_PERL == 1) {
+$r-register_cleanup(\CGI::_reset_globals);
+}
+else {
+$r-pool-cleanup_register(\CGI::_reset_globals);
+}
+undef $NPH;
}
$self-_reset_globals if $PERLEX;
$self-init($initializer);
@@ -1279,13 +1288,21 @@
push(@header,map {ucfirst $_} @other);
push(@header,Content-Type: $type) if $type ne '';
-my $header = join($CRLF,@header).${CRLF}${CRLF};
if ($MOD_PERL and not $nph) {
my $r = Apache-request;
- $r-send_cgi_header($header);
+for (@header) {
+my($k, $v) = split /:\s+/, $_, 2;
+if ($k eq 'Content-Type') {
+$r-content_type($v);
+}
+else {
+$r-headers_out-{$k} = $v;
+}
+}
+ $r-send_http_header() if $MOD_PERL == 1;
return '';
}
-return $header;
+return join($CRLF,@header).${CRLF}${CRLF};
}
END_OF_FUNC
--- CGI/Carp.pm.orig2003-03-11 11:51:28.0 +1100
+++ CGI/Carp.pm 2003-03-11 12:30:02.0 +1100
@@ -358,9 +358,9 @@
# eval. These evals don't count when looking at the stack backtrace.
sub _longmess {
my $message = Carp::longmess();
-my $mod_perl = exists $ENV{MOD_PERL};
-$message =~ s,eval[^\n]+Apache/Registry\.pm.*,,s if $mod_perl;
-return $message;
+$message =~ s,eval[^\n]+(ModPerl|Apache)/Registry\w*\.pm.*,,s
+if exists $ENV{MOD_PERL};
+return $message;
}
sub ineval {
@@ -452,14 +452,25 @@
END
;
-if ($mod_perl (my $r = Apache-request)) {
+if ($mod_perl) {
+require mod_perl;
+if ($mod_perl::VERSION = 1.99) {
+$mod_perl = 2;
+require Apache::RequestRec;
+require Apache::RequestIO;
+require Apache::RequestUtil;
+require APR::Pool;
+require ModPerl::Util;
+require Apache::Response;
+}
+my $r = Apache-request;
# If bytes have already been sent, then
# we print the message out directly.
# Otherwise we make a custom error
# handler to produce the doc for us.
if ($r-bytes_sent) {
$r-print($mess);
- $r-exit;
+ $mod_perl == 2 ? ModPerl::Util::exit(0) : $r-exit;
} else {
$r-status(500);
$r-custom_response(500,$mess);
--- CGI/Pretty.pm.orig 2003-03-11 11:51:47.0
ANNOUNCE: Apache-VMonitor 0.8
Changes since 0.7 * prevent cross-site scripting, now HTML-escaping the request field * mention in the docs that ExtendedStatus On is not coming for free. The uploaded file Apache-VMonitor-0.8.tar.gz has entered CPAN as file: $CPAN/authors/id/S/ST/STAS/Apache-VMonitor-0.8.tar.gz size: 18209 bytes md5: 88cfba14794b50cb0642931cd19d42da No action is required on your part Request entered by: STAS (Stas Bekman) Request entered on: Tue, 11 Mar 2003 04:01:10 GMT Request completed: Tue, 11 Mar 2003 04:01:42 GMT Virtually Yours, paused, v276 -- __ 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::SubRequest::run
Daniel Risacher wrote: The Cookbook talks about the 'run' method of a SubRequest, and claims that passing a single true argument to this method will cause the subrequest to send headers (otherwise they are suppressed). I went and found the code that does this in mp1 (it clears the assbackward flag of the RequestRec before running the subrequest) This functionality seems to be missing in mp2. Is this intentional? If so, is there some other way to run a subrequest and have it send all the headers? Somebody has asked the same question a few days ago, I've replied here (I couldn't make his code working in 1.0): http://marc.theaimsgroup.com/?l=apache-modperlm=104682701824401w=2 Does your code work with mp1? Please post here a short handler/script that works with 1.0, but not with 2.0, so we'll be able to reproduce it and fix it if it's really broken. __ 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] Documentation
[EMAIL PROTECTED] wrote: I'll get this project out the door, and start with an 'all-you-ever-wanted-to-know-about-uri-parsing' tutorial. Give me 1 week. Great Beau! Though make sure that you write it in pod, and not HTML ;) If you have any questions regarding format please ask (preferrably on the docs-dev list). Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reading an array from perl script
[please keep the posts on the list! thanks] Devi .M wrote: Hello, I used IPC::Shareable for sharing 3 arrays between 2 process . Among those, 2 are 2D arrays and one is 3D array. Its woking fine for 2D arrays but does not work for 3D array. If I modify the values in the 3D array its not reflecting in the main script itself. I am struggling with this for the past 2 days and could not find a solution. When I tried the same thing with a simple script for 3D array it is working fine. Is there anything with memory size? If so how we have to specify the size and how can I get the size of an array. Kindly help me to overcome this. Have you read the followup from Perrin on this thread? If not, check the archives. To figure out the size see Devel::Size http://search.cpan.org/search?query=devel%3A%3Asizemode=module and B::Size/B::TerseSize http://search.cpan.org/search?query=b%3A%3Asizemode=module Devi .M wrote: Hello All, I have a perl script that would be running infinitely and updating an array by processing some data. Now I would like to read the array values that should not disturb this perl script. I thought to use the concept of shared variable and write a method in perl module which contains the array sharring with the infinitely running perl script and return me the updated array values. But don't know how to proceed with this. Could anyone help me out? I'm assuming that you need to connect to it from mod_perl, otherwise this question is quite offtopic here ;) As suggested by Mark, IPC::Shareable might work if the data set is small. If it's big you can use a simple dbm to store the data in and with proper locking read/write to/from it without disturbing each other. __ 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 -- __ 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] CGI redirects incorrectly handled?
Mark James wrote: Stas Bekman wrote: Can you send a short script (removing all the irrelevant bits) that we can reproduce the problem with? Made a script that generated the same POST request and same redirect as the problem code. The problem was not reproduced! The only difference I can see between working POSTs (both those in my package code and the one in the test script) and the failing one (a particular one in my package) is in the distribution of the data across the TCP packets that carry the POST. [snippet the packet dumps] Could mod_perl, with its persistent buffer, be tripping up on this? I'm trying now to trace the data through the mp2 code. -- Mark mod_perl 2.0 is buffering only the content (response body, not the headers) (assuming that you aren't installing any output filters), so it's one of the apache core output filters, that decides how to split the data. a normal output filter list ends with: byterange(0x8841110): ctx=0x0, r=0x88402d0, c=0x883a390 content_length(0x8841128): ctx=0x0, r=0x88402d0, c=0x883a390 http_header(0x8841140): ctx=0x0, r=0x88402d0, c=0x883a390 core(0x883a760): ctx=0x883a738, r=0x0, c=0x883a390 you can dump this, using the dump_filters macro, which you can load by running gdb source /path/to/httpd-2.0/.gdbinit the 'core' filter is in httpd-2.0/src/core.c: core_output_filter(...) __ 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: Trouble with sysread in modperl
Liu, Hui (GXS) wrote:
Stas,
Yes we tried reading STDIN and it works:
while ($readData = STDIN) {
$buffer.= $readData;
$bufferLength = length($buffer);
..
}
But it's not working with sysread or read, here are the results
for read, the last line is what we expected but it's null:
while ($bytesRead = read(STDIN, $buffer, 4096)) {
html(bytesRead=[$bytesRead] data=[$buffer]) if ($debug);
}
Here's the results from the above code :
I suggest that you look at the implementation of the function read_multipart()
in CGI.pm, which does exactly what you want. (I see no reason why not using
CGI.pm in first place if you can.)
And please, refrain from posting emails with huge chunks of useless
information, in the future. Truncate to keep only the information that may
help to understand and reproduce the problem.
__
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: DECLINE, ERRORs in the middle of hanlers stack
Ruslan U. Zakirov wrote: On Sat, 8 Mar 2003, Stas Bekman wrote: Ruslan U. Zakirov wrote: Hello All! Stacked handlers is a very useful technology, but as I think incomplete. I need some suggestions. My project split content handler in the few parts. And each handler send part of the requested page to user, but sometimes I must stop proccessing and return DECLINE, redirect user or return some ERROR. Error appear in the middle of the page. I want Apache to buffer content and send it after last handler in chain return OK. Is it possible? Sure, you can buffer the data using $r-notes or $r-pnotes and have the last handler send it out. But instead of stuffing the content there, you are probably better off (more efficient?) to create a buffering class, instantiate an instance, and store it in $r-pnotes between invocations. Hello Stas and other! Thanks for idea, but it force me to change all scripts. Another alternative is to try using Apache::Filter for the buffering and $r-notes/pnotes for flow control (so you can inform Apache::Filter what to do with the buffered data). mod_perl 2.0 filters are probably more flexible, but I see no reason why mp1's Apache::Filter won't do the job. __ 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: Trouble with sysread in modperl
Liu, Hui (GXS) wrote: Stas, Does this mean read or sysread not work properly in mod_perl and we should stay away from the two functions if we write perl code to work with Apache server? I haven't said that. I doubt so. It could be a bug in your code. I've suggested: I suggest that you look at the implementation of the function read_multipart() in CGI.pm, which does exactly what you want. (I see no reason why not using CGI.pm in first place if you can.) Have you tried that? Also I'm assuming that you are using mod_perl 1.x, right? __ 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: problems installing mod_perl 2
Carlos Villegas wrote: Hi, First some basic info: -Apache 2.0.44 -Solaris 9 sparc -perl 5.8.0 -mod_perl-1.99_08 (from mod_perl-2.0-current.tar.gz) -complete newbie to mod_perl I had some problems to compile mod_perl: make test would fail, after reading the mailing list archives, I found a few things related to my problem, so I added a few lines to: t/hooks/TestHooks/init.pm and t/hooks/TestHooks/trans.pm (I can post a diff if it's of interest) Certainly. But please follow the bug reporting guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems This fixed some problems, but not all of them. I decided to ignore further failures of make test, and did a make install, it failed (?), however I did get a mod_perl.so under $apacheroot/modules, so I added the LoadModule line to apache, and restarted it. It seems to work, however I can't load my module (using PerlHandler mymodule), because it can't find Apache::Constants (which I use in my module). I have tried to install this (Apache::Constants) by using the shell of CPAN, but it refuses to install for apache2, I saw some references to Apache2 somewhere in the archives, but couldn't find it either (using CPAN shell). Does make install add some more stuff besides mod_perl.so? My perl is in a read only path, so this might be the problem, but I'm not sure... Which are the specific dependencies for mod_perl 2? It's all very well documented. Please spend some time at: http://perl.apache.org/docs/2.0/index.html in particular: http://perl.apache.org/docs/2.0/user/compat/compat.html How stable is mod_perl 2? Getting better every day. There are still problems here and there, but they get resolved when reported. See the todo directory and the STATUS file in the mod_perl source for things that are still missing. __ 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
porting modules to mp2 docs are updated
Since the questions of porting to mp 2.0 are on raise, and there is some confusion regarding use of Apache::compat. I've done a massive porting docs update: Please review the following if you are involved in porting, and let me know if I've missed something or if something is still unclear: http://perl.apache.org/docs/2.0/devel/porting/porting.html http://perl.apache.org/docs/2.0/api/Apache/compat.html http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html p.s. the site is being updated right now, so please wait for 20 minutes or so as the pdfs are crunched. __ 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
Ask Bjoern Hansen wrote: On Thu, 6 Mar 2003, Stas Bekman wrote: re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) __ 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] automatic Apache::compat preloading in CPAN modules isa no-no
Stas Bekman wrote:
Apache::compat is useful during the mp1 code porting. Though remember
that it's implemented in pure Perl. In certain cases it overrides mp2
methods, because their API is very different and doesn't map 1:1 to mp1.
So if anything, not under my control, loads Apache::compat my code is
forced to use the potentially slower method. Which is quite bad.
Some users may choose to keep using Apache::compat in production and it
may perform just fine. Other users will choose not to use that module.
It should be users' choice.
Therefore CPAN modules should *not* preload Apache::compat, but use the
mp2 API or copy the relevant parts from Apache::compat.
Of course one can add an ugly workaround in startup.pl:
$INC{'Apache/compat.pm'} = __FILE__;
but I'd rather not have to remember doing that. I'll update the manpage
to have this warning.
I haven't scanned the CPAN modules yet, but I've noticed that CGI.pm's
latest version does:
require mod_perl;
if ($mod_perl::VERSION = 1.99) {
eval require Apache::compat;
} else {
eval require Apache;
}
Lincoln, any chance we can kill that preloading? If you need help with
porting the API please let us know.
Here is a hopefully useful discussion and examples on how to get rid of
Apache::compat:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Handling_Missing_and_Modified_mod_perl_1_0_APIs
__
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
