Can't locate object method new via package Apache::Request
Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. So, for Apache::Test I proceed to make clean and then do: perl Makefile.PL make make test results of make test /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APXS= APACHE_PORT= APACHE_GROUP= APACHE= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/sbin/httpd -X -d /root/.cpan/build/Apache-Test-1.03/t -f /root/.cpan/build/Apache-Test-1.03/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started ping...ok requestFAILED tests 1, 5, 8-9 Failed 4/9 tests, 55.56% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- request.t 94 44.44% 1 5 8-9 *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) make: *** [run_tests] Error 1 /results from make test everything in t/logs/error_log [Sun Aug 24 21:16:49 2003] [info] Created shared memory segment #4259853 [Sun Aug 24 21:16:49 2003] [info] allocated semaphore #3112976 [Sun Aug 24 21:16:50 2003] [info] Created shared memory segment #4358157 [Sun Aug 24 21:16:50 2003] [info] allocated semaphore #3178512 [Sun Aug 24 21:16:50 2003] [info] created shared memory segment #4423695 /everything in t/logs/error_log I then did a make install and it installed the files, but they are broken. At any rate, I tried libapreq with the following: make clean perl Makefile.PL -httpd /usr/sbin/httpd /results from perl Makefile.PL -httpd /usr/sbin/httpd generating script t/TEST Checking if your kit is complete... Looks good Writing Makefile for libapreq mkdir ../blib mkdir ../blib/arch mkdir ../blib/arch/auto mkdir ../blib/arch/auto/libapreq Warning: -L../blib/arch/auto/libapreq changed to -L/root/.cpan/build/libapreq-1.2/Request/../blib/arch/auto/libapreq Writing Makefile for Apache::Request Warning: -L../blib/arch/auto/libapreq changed to -L/root/.cpan/build/libapreq-1.2/Cookie/../blib/arch/auto/libapreq Writing Makefile for Apache::Cookie Writing Makefile for libapreq /results from perl Makefile.PL -httpd /usr/sbin/httpd make make test results from make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Cookie' /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APXS= APACHE_PORT= APACHE_GROUP= APACHE= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/sbin/httpd -X -d /root/.cpan/build/libapreq-1.2/t -f /root/.cpan/build/libapreq-1.2/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost.localdomain:8529 started apreq/big_inputFAILED tests 1-21 Failed 21/21 tests, 0.00% okay apreq/cookie...FAILED test 1 Failed 1/1 tests, 0.00% okay apreq/inherit..FAILED test 1 Failed 1/1 tests, 0.00% okay apreq/request..FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apreq/big_input.t 21 21 100.00% 1-21 apreq/cookie.t 11 100.00% 1 apreq/inherit.t 11 100.00% 1 apreq/request.t 22 100.00% 1-2 *** server localhost.localdomain:8529
RE: Can't locate object method new via package Apache::Request
I ran into the same problem. What I had to do was compile libapreq as a shared library first. That solved things nicely. HTH. Regards, S. G. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method new via package Apache::Request
On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: Can't locate object method new via package Apache::Request
Ok, in the libapreq module I did the configure ./configure --with-apache-includes=/usr/includes/apache make make install Everything compiled just fine. Then did perl Makefile.PL make make test make install All of the tests still failed and the t/logs/error_log still reported: [Sun Aug 24 23:01:32 2003] [info] Created shared memory segment #5275663 [Sun Aug 24 23:01:32 2003] [info] allocated semaphore #3768340 [Sun Aug 24 23:01:33 2003] [info] Created shared memory segment #5373967 [Sun Aug 24 23:01:33 2003] [info] allocated semaphore #3833876 [Sun Aug 24 23:01:33 2003] [info] created shared memory segment #5439505 Any advice how I proceed from here? Thanks Kevin On Sun, 2003-08-24 at 22:49, S.B.S wrote: I ran into the same problem. What I had to do was compile libapreq as a shared library first. That solved things nicely. HTH. Regards, S. G. -- K Old [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method newvia package Apache::Request
On Mon, 2003-08-25 at 14:45, Stas Bekman wrote: K Old wrote: On Mon, 2003-08-25 at 13:13, Stas Bekman wrote: K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: Hello everyone, I've put HTML::Mason on a few servers now and have had problems with Apache::Request and Apache::Test on two of them. My most recent is having the problem and I'm about to go crazy if I don't figure out why installs keep having problems. Here's my setup: RH 7.2, Apache 1.3.27, mod_perl 1.26, Perl 5.6.1 - all installed from RPM's. I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm line 14 Compilation failed in require at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. BEGIN failed--compilation aborted at /home/admin/libapreq-1.2/t/response/TestApReq/big_input.pm line 9. Compilation failed in require at (eval 4) line 3. That's a known linking problem. It has been fixed in the cvs, get the cvs instructions from http://httpd.apache.org/apreq/. Joe, may be a new 1.x version should be released? Stas, I've downloaded the CVS, unpacked, built and tested with a not root user, and still received the same errors as before. Here's the syntax I'm using for build, etc: (CVS version) perl Makefile.PL make make test (Module from CPAN) perl Makefile.PL make make test then ./configure --with-apache-includes=/usr/include/apache make make install perl Makefile.PL make make test Is there anything I'm not doing right? I've tried to disable the FrontPage stuff so that the non root user should be able to start apache without the errors, but either by root or non root user I get the same error messages regarding Cookie.so and so forth. That probably means that my patches weren't applied. K Old, see http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w=2 Does it solve the problem for you? Stas, That did it! And to answer your question, no it doesn't look like your changes were committed. Thank you so much for your assistance with this! I really appreciate it! Kevin -- K Old [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Mason] Can't locate object method new via package Apache::Request
On Mon, 25 Aug 2003, K Old wrote: On Mon, 2003-08-25 at 00:18, Randy Kobes wrote: On Sun, 24 Aug 2003, K Old wrote: [ ... ] I did a install HTML::Mason from the CPAN command line and all the dependencies were downloaded and some didn't compile. The two that didn't are Apache::Test-1.03 and libapreq-1.2. [ .. ] Regarding the failure of the tests in these two packages, what happens if you unpack, build, and test these as a non-root user, only becoming root to install them? There's some subtelties running the tests as root. Randy, Ok, yes, this worked...to a point! I pulled down fresh copies of the modules from CPAN, unpacked, build and tested with another user. All tests were successful with Apache::Test with the normal user, but I had to go to root for the tests for libapreq1.2 as my webserver needed the root user to start FrontPage services. Is it possible to disable FrontPage just to see if the libapreq tests are OK when run as another user? Doing the make test for libapreq-1.2 all test fail and I get this in the t/logs/error_log: [Mon Aug 25 08:49:12 2003] [error] Can't load '/home/admin/libapreq-1.2/blib/arch/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. [ ... ] I've tried to install DynaLoader.pm from CPAN, but it says it's up to date. That error message means that libapreq.so, which is required by Apache::Cookie, couldn't be loaded. Do you have a libapreq.so under /home/admin/libapreq-1.2/blib/? And if so, does it have the permissions set so that the user under which the web server is running as can load it? -- best regards, randy -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Trouble with Apache::Request
On Fri, 1 Aug 2003, Jie Gao wrote:
Hi All,
perl-5.8.0 + mp1.99_10.
---
I am having problem trying to get /perl-status work.
It bombs out in Status.pm at the following location:
--
if (eval {require Apache::Request}) {
$newQ ||= sub { Apache::Request-new(@_) };
}
elsif (eval {require CGI}) {
$newQ ||= sub { CGI-new; };
}
else {
die Need CGI.pm or Apache::Request to operate;
}
--
But shouldn't Apache::Request be Apache::RequestRec?
Apache::Request is part of the libapreq package, a port of
which to Apache2 is still being developed.
best regards,
randy kobes
Re: Trouble with Apache::Request
On 6 Jun 2003, K Old wrote: [...] Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. This patch resolves this problem: http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w=2 it should go in in the next release. __ 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 Apache::Request
I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run ldconfig .. Worked for me and I was messing with the darn thing for about 3 hours. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : On 6 Jun 2003, K Old wrote: : : [...] : : Well, here are the errors I'm getting: : : When I *force* and install of Apache::Request and a script calls : Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : [error] Can't locate object method new via package : Apache::Request : at : : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : pm : line 22. : : This is from doing a make test when trying to install : Apache::Request : manually: : : Syntax error on line 31 of : /root/.cpan/build/libapreq-1.1/t/httpd.conf: : Can't load : : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : line 14 : Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w= 2 it should go in in the next release. __ 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 Apache::Request
Glenn E. Bailey III wrote: I had this exact same issue yesterday. I noticed that is was installing the libapreq.so.1 in /usr/local/lib and /usr/local/lib wasn't in my /etc/ld.so.conf file. Just add /usr/local/lib to your /etc/ld.so.conf file and then run ldconfig .. Worked for me and I was messing with the darn thing for about 3 hours. It shouldn't have installed it in first place. actually there are a few more patches on win32 that will go in soon. A new release will make those problems go away. . Glenn E. Bailey III . Sprocket Data, Inc. . http://www.sprocketdata.com : -Original Message- : From: Stas Bekman [mailto:[EMAIL PROTECTED] : Sent: Thursday, July 31, 2003 6:48 AM : To: K Old : Cc: ModPerl List : Subject: Re: Trouble with Apache::Request : : : On 6 Jun 2003, K Old wrote: : : [...] : : Well, here are the errors I'm getting: : : When I *force* and install of Apache::Request and a script calls : Apache::Request, this is in the error_log: [Fri Jun 6 : 17:27:31 2003] : [error] Can't locate object method new via package : Apache::Request : at : : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request. : pm : line 22. : : This is from doing a make test when trying to install : Apache::Request : manually: : : Syntax error on line 31 of : /root/.cpan/build/libapreq-1.1/t/httpd.conf: : Can't load : : '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/ : Request.so' for module Apache::Request: libapreq.so.1: cannot : open shared object file: No such file or directory at : /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. : at : /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm : line 14 : Compilation failed in require at (eval 16) line 3. : : This patch resolves this problem: : http://marc.theaimsgroup.com/?l=apreq-devm=105965131008577w= 2 it should go in in the next release. __ 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: Trouble with Apache::Request
Hi All,
perl-5.8.0 + mp1.99_10.
---
I am having problem trying to get /perl-status work.
It bombs out in Status.pm at the following location:
--
if (eval {require Apache::Request}) {
$newQ ||= sub { Apache::Request-new(@_) };
}
elsif (eval {require CGI}) {
$newQ ||= sub { CGI-new; };
}
else {
die Need CGI.pm or Apache::Request to operate;
}
--
But shouldn't Apache::Request be Apache::RequestRec?
Sincerely,
Jie
Re: Question about Apache::Request and query strings
Tom Gazzini wrote:
I have a perl function which, amongst other things, needs to redirect
the request to another page.
It also needs to pass all the query parameters of the original request
(both GET and POST) to the redirected page, and also add one parameter
of it's own (an error message).
Sounds simple enough, but I'm having problems with the passing paramters
bit.
Here's what I have:
sub show_error {
my ($r, $error) = @_;
# $r is an Apache:Request object passed by the caller
my $uri = URI-new($url);
foreach my $p (@params) {
$uri-query_form($p = $r-param($p));
}
$uri-query_form(error = $error);
$r-internal_redirect($uri-canonical);
}
But this doesn't work. The '?error=' query string gets passed, but the
orginal request query strings don't.
What am I doing wrong? And is there an easier way?
This example may help:
http://perl.apache.org/docs/1.0/guide/snippets.html#Reusing_Data_from_POST_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: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote: Hi Joe -- +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). Perhaps you could bullet-point a few of these possibilities for those of us who are confined by our lack of imagination? Check out the guide: http://perl.apache.org/guide/ Check out the books: http://perl.apache.org/docs/offsite/books.html Check out the success stories: http://perl.apache.org/outstanding/success_stories/index.html TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 signature.asc Description: This is a digitally signed message part
RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)
Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Jesse Erlbaum wrote: Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. I like to think that Part III (Chapters 11-17) of the mod_perl Developer's Cookbook does some of that. authentication is a good example of how mod_perl enables life outside of CGI scripting. if you require authentication in your application, auth handlers allow you to entirely remove authentication from your content handlers. mod_perl allows you to let your content handlers to focus on content - all other parts of your application (authentication, session management, proxying, URL rewriting tricks, etc) can programmed at the server level via other parts of the request cycle. I'm talking about this at a very basic level at OSCon this year (as I did last year), but you might be interested in my slides from YAPC2002 to get a general feel for it (and ApacheCon if you want to see the more twisted side of what mod_perl opens up). http://www.modperlcookbook.org/~geoff/slides/ HTH --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Hello, GYmod_perl allows you to let your content handlers to focus on content - GYall other parts of your application (authentication, session management, GYproxying, URL rewriting tricks, etc) can programmed at the server level GYvia other parts of the request cycle. I think the question isn't why is Apache::Registry not sufficient to handle all functions within an HTTP request but why is it bad to use Apache::Request specifically for the content generation phase? Perrin had some good practical reasons for this--caused by the generated-namespace, sub-wrapped, eval'ed nature of Apache::Registry. I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. I think it's a fine tool for simple content generation scripts and that it doesn't limit you at all in that aspect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this http://www.perl.com/pub/a/2002/02/20/css.html while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool. other cool stuff comes at the end of this talk, http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz which touches on Apache::Registry-as-legacy-CGI-wrapper limitations see also http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz which handles the issue of merging legacy CGI Registry scripts with POST data issues and http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz which addresses the fact that Registry does not properly handle HEAD requests. given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection. --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs.mod_perlhandler philosophy)
On Wed, 2003-07-02 at 20:38, Andrew Ho wrote: I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script I would phrase it differently and say that there are nice things you can do when you embrace the fact that you're in a persistent environment. You can do a lot of things in ways that are compatible with both CGI and mod_perl, by checking the environment and acting appropriately, but it can be a pain when you want to take advantage of cleanup handlers, preloaded data, persistent connections, etc. You can do all this from A::R, but once you've decided to write something that is not going to work under CGI I can't see any reason to use A::R anymore. At that point, it's just an artificial construct that adds complexity to your system. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. People often say this. I just don't see it. Apache::Reload works just as well. My dev server restarts in about a second, so I always restart it when I make a change just to feel confident that I'm not seeing any residual effects from previous code. The whole reload thing is not perfect anyway, and people have had problems with A::R's reload when working with code that has closures in it. My opinion is that you should use A::R if you need CGI (or SpeedyCGI, etc.) compatibility, but use handlers otherwise. - Perrin
Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Perrin Harkins [EMAIL PROTECTED] writes: [...] I'm late to the party, but here's an old post of mine that sums up my opinion: http://marc.theaimsgroup.com/?l=apache-modperlm=95440118003848w=2 +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). That said, apreq-dev is looking for someone to adopt and develop the CGI port of libapreq-2/Apache::Request. I'm shooting for a developer release of libapreq-2 before OSCON, and it'd be _really_ cool if we had a functional CGI port available. -- Joe Schaefer
Re: Question about Apache::Request and query strings
Tom
Where's @params coming from ?
Are you sure it's not empty ?
Swen
|-+
| | Tom Gazzini|
| | [EMAIL PROTECTED]|
| | uk |
| ||
| | 06/26/2003 04:42 |
| | PM |
| ||
|-+
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Question about Apache::Request and query strings
|
|
|
|
|
--|
I have a perl function which, amongst other things, needs to redirect
the request to another page.
It also needs to pass all the query parameters of the original request
(both GET and POST) to the redirected page, and also add one parameter
of it's own (an error message).
Sounds simple enough, but I'm having problems with the passing paramters
bit.
Here's what I have:
sub show_error {
my ($r, $error) = @_;
# $r is an Apache:Request object passed by the caller
my $uri = URI-new($url);
foreach my $p (@params) {
$uri-query_form($p = $r-param($p));
}
$uri-query_form(error = $error);
$r-internal_redirect($uri-canonical);
}
But this doesn't work. The '?error=' query string gets passed, but the
orginal request query strings don't.
What am I doing wrong? And is there an easier way?
Thanks,
Tom
Re: apache::request parse() doesn't capture abort error
Hector Pizarro [EMAIL PROTECTED] writes:
[...]
If the user closes the popup in the middle of an upload, Apache::Request
parse() isn't throwing any error, and all the following code in my module
savesthe file incomplete in the system, which of course is garbage data.
Is this a bug, an incomplete feature, or is my configuration?
It's probably a bug in c/apache_multipart_buffer.c. We may not
do error-checking well enough on fill_buffer().
If parse is supposed to return an error code, which one is that? 206 =
HTTP_PARTIAL_CONTENT?
No, that's not an error code. Since the error here seems
to arise from ap_get_client_block, $r-status should probably
be -1.
Ok, now let's suppose that this error is fixed.
With a patch, I hope ;-).
I want to do several uploads fromthe same popup at once, so I have 5
file boxes in the form. If the user closesthe popup before the process
ends, i'd like to save only the completed files, how could I check
which files are correctly uploaded, and which ones are incomplete?
You could just ignore the final upload object, which has no - next
pointer:
for (my $u = $req-upload; $u $u-next; $u = $u-next) {
# do something with $u
}
--
Joe Schaefer
apache::request parse() doesn't capture abort error
Hello, first this is my configuration, all were installed by hand: - apache 1.3.27 - libapreq-1.1 - mod_perl 1.27 the users of this project can upload big files to the website (videos mostly). SoI use an html popup where a mod_perl handler receives the data, let's suppose its 100Mb. If the user closes the popup in the middle of an upload, Apache::Request parse() isn't throwing any error, and all the following code in my module savesthe file incomplete in the system, which of course is garbage data. Is this a bug, an incomplete feature, or is my configuration? If parse is supposed to return an error code, which one is that? 206 = HTTP_PARTIAL_CONTENT? Ok, now let's suppose that this error is fixed. I want to do several uploads fromthe same popup at once, so I have 5 file boxes in the form. If the user closesthe popup before the process ends, i'd like to save only the completed files, how could I check which files are correctly uploaded, and which ones are incomplete? Any help would be great people, thanks. -- Hector Pizarro Amautatech
an update on Apache::Request 2.0 progress
BTW, Apache::Request's 2.0 port is moving forward very fast thanks to Joe Schaefer's efforts. He is looking for help, at least with testing the perl glue. If you are interested to help, join the apreq-dev list: http://httpd.apache.org/apreq/ __ 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 Apache::Request
On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? -- best regards, randy
Re: Trouble with Apache::Request
On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? Well, I've recompile a fresh version of Perl 5.8.0 (without threads), Apache, mod_perl and PHP and still no luckon that box. I have another Mandrake 9.0 box and tried to compile the new libapreq that Stas pointed to from CVS and got the following errors Any suggestions? I did: perl Makefile.PL -httpd /usr/sbin/httpd make test And got: In file included from apache_request.c:59: apache_request.h:5:19: httpd.h: No such file or directory apache_request.h:6:25: http_config.h: No such file or directory apache_request.h:7:23: http_core.h: No such file or directory apache_request.h:8:22: http_log.h: No such file or directory apache_request.h:9:23: http_main.h: No such file or directory apache_request.h:10:27: http_protocol.h: No such file or directory apache_request.h:11:25: util_script.h: No such file or dmake[1]: Leaving directory `/root/tmp/httpd-apreq/c' pache_request.h:38: parse error before table apache_request.h:38: warning: no semicolon at end of struct or union apache_request.h:47: parse error before '*' token apache_request.h:47: warning: data definition has no type or storage class apache_request.h:49: parse error before '}' token apache_request.h:49: warning: data definition has no type or storage class apache_request.h:56: parse error before table apache_request.h:56: warning: no semicolon at end of struct or union apache_request.h:57: warning: data definition has no type or storage class apache_request.h:59: parse error before '*' token apache_request.h:59: warning: data definition has no type or storage class apache_request.h:60: parse error before '}' token apache_request.h:90: parse error before '*' token apache_request.h:90: parse error before '*' token apache_request.h:90: warning: data definition has no type or storage class apache_request.h:91: parse error before '*' token apache_request.h:92: parse error before '*' token apache_request.h:93: parse error before '*' token apache_request.h:94: parse error before '*' token apache_request.h:95: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: warning: data definition has no type or storage class apache_request.h:97: parse error before '*' token apache_request.h:98: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: warning: data definition has no type or storage class apache_request.h:102: parse error before '*' token apache_request.h:102: parse error before '*' token apache_request.h:102: warning: data definition has no type or storage class apache_request.h:104: parse error before '*' token apache_request.h:104: parse error before '*' token apache_request.h:104: warning: data definition has no type or storage class apache_request.h:105: parse error before '*' token apache_request.h:124: parse error before '*' token apache_request.h:127: parse error before '*' token In file included from apache_request.c:60: apache_multipart_buffer.h:16: parse error before request_rec apache_multipart_buffer.h:16: warning: no semicolon at end of struct or union apache_multipart_buffer.h:29: parse error before '}' token apache_multipart_buffer.h:29: warning: data definition has no type or storage class apache_multipart_buffer.h:31: parse error before '*' token apache_multipart_buffer.h:32: parse error before request_rec apache_multipart_buffer.h:32: warning: data definition has no type or storage class apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: warning: data definition has no type or storage class apache_multipart_buffer.h:34: parse error before '*' token apache_multipart_buffer.h:35: parse error before '*' token apache_multipart_buffer.h:36: parse error before '*' token apache_request.c:61: parse error before '*' token apache_request.c:69: parse error before '*' token apache_request.c: In function `util_read': apache_request.c:71: `request_rec' undeclared (first use in this function) apache_request.c:71: (Each undeclared identifier is reported only once apache_request.c:71: for each function it appears in.) apache_request.c:71: request for member `r' in something not a structure or union apache_request.c:72: `OK' undeclared (first use in this function) apache_request.c:74: `REQUEST_CHUNKED_ERROR' undeclared (first use in this
Re: Trouble with Apache::Request
On Sun, 8 Jun 2003, K Old wrote: On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? Well, I've recompile a fresh version of Perl 5.8.0 (without threads), Apache, mod_perl and PHP and still no luckon that box. I have another Mandrake 9.0 box and tried to compile the new libapreq that Stas pointed to from CVS and got the following errors Any suggestions? I did: perl Makefile.PL -httpd /usr/sbin/httpd make test And got: In file included from apache_request.c:59: apache_request.h:5:19: httpd.h: No such file or directory [ .. ] Is /usr/sbin/httpd is a symbolic link to a real httpd, which could be something like /usr/local/httpd/bin/httpd? And is this httpd the one you compiled? If so, try giving the full path to this httpd as the Makefile.PL argument (there should be a /usr/local/httpd/include/ directory which has the header (.h) files that couldn't be found). -- best regards, randy
Trouble with Apache::Request
Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! -- K Old [EMAIL PROTECTED]
RE: Trouble with Apache::Request
Kitch, No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works, as I'm out of things to try. Thanks, Kevin On Fri, 2003-06-06 at 12:39, Kitch, David wrote: Did you do a threaded build of Perl 5.8.0? You might try a non-threaded Perl build. Regards, Kitch [EMAIL PROTECTED] -Original Message- From: K Old [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 11:27 AM To: ModPerl List Subject: Trouble with Apache::Request Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so ' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated!
RE: Trouble with Apache::Request
Hi there, On 6 Jun 2003, K Old wrote: No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works Want to run that by me again?? I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. Is it *exactly* the same error? Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. [snip] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ for module Apache::Request: libapreq.so.1: cannot open shared object file: \ No such file or directory [snip] Is there in fact no such file or directory? I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. 73, Ged.
Re: Trouble with Apache::Request
On Fri, 6 Jun 2003, K Old wrote: Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. [ .. ] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! If there's more than one Apache on your system, it may be that libapreq found the wrong one. Does it help any if you specify explicitly the desired Apache at the 'perl Makefile.PL' stage, as discussed in the install file of the distribution? -- best regards, randy kobes
RE: Trouble with Apache::Request
Hi Ged, On Fri, 2003-06-06 at 13:55, Ged Haywood wrote: Hi there, On 6 Jun 2003, K Old wrote: No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works Want to run that by me again?? Mandrake 9.0 (and several other linux distros) come out of the box with Perl 5.8.0 built with threads. I'm guessing that having Perl compiled with threads might be what's causing the problem in getting Apache::Request installed. I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. Is it *exactly* the same error? Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Still with the forced install of Apache::Request, if I try to call it from httpd.conf via PerlModule Apache::Request, I get this error. Syntax error on line 590 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. I'm starting to agree. Just this afternoon I build Apache::Request without any problems on an RH 7.3 box with Perl 5.6.1 compiled without threads. Anyone else have Apache::Request running under Perl 5.8.0 with threads enabled? [snip] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ for module Apache::Request: libapreq.so.1: cannot open shared object file: \ No such file or directory [snip] Is there in fact no such file or directory? The file Requests.so does exist and it is in the location being referenced. The permissions are 755. I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. Yeah, I hear ya on the CPAN thingI am building it as root, but have tried it as a regular user and get the same errors Any ideas? Thanks for your help, Kevin -- K Old [EMAIL PROTECTED]
Re: Trouble with Apache::Request
[ CC'ing the apreq-dev list. In the future please post apreq build problems questions to the apreq-dev list: http://httpd.apache.org/apreq/ ] K Old, please try the httpd-apreq cvs version: I just did: % cd httpd-apreq % perl-5.8.0-ithread Makefile.PL -httpd /home/httpd/httpd_perl/bin/httpd make test ... All tests successful. This version will be soon released on CPAN, it wasn't released yet due to some polishing of Apache::Test that is now used by Apache::Request for its test suite. Here is how to get the cvs version: % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login CVS password: anonymous % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co httpd-apreq % cd httpd-apreq % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co \ -d Apache-Test httpd-test/perl-framework/Apache-Test notice that in the example above, you need to adjust a path to your httpd and of course the path to perl, perl-5.8.0-ithread in my case is a symlink to perl-5.8.0 built with threads. If your problem still persists please post the output of your 'perl -V' that you have used to build 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
Subclassed Apache::Request Objects and their creation/destruction
All,I'm
looking for some help with understanding how the Apache::Request objectsare
created and destroyed.I have the following params set in my
httpd.confKeepAlive OffPerlChildInitHandler
Bficient::Apache::DBloadWhich as I understand it should mean that an
apache::Request object iscreated for each request, and is destroyed at the
end of a request.So if I add 'CREATION and DESTROY' warnings to my
Apache::Request code tolog when a request is being created and destroyed I
should see the objectsbeing created and destroyed as they are
used.This would lead me to believe that when I stop apache, the only
DESTROYmessages I should see are those belonging to the childInitHandler,
e.g. Ishould see my database handles being destroyed.I'm just trying
to get an understanding of what 'should' happen, so that Ican work out If I
have a problem with my code.I have subclassed Apache::Request and I'm
seeing my subclassedApache::Request objects being'DESTROYED' under an
apache stop. AS WELL as after the Request completes,e.g.after the
request completes I see this:-$VAR1 = bless(
{
'r' = bless( do{\(my $o = 145326836)}, 'Apache::Request'
)
}, 'Bficient::Apache::Request' );DESTROYING
Bficient::Apache::RequestBut when I stop apache I see
this:-$VAR1 = bless(
{
'r' =
undef
}, 'Bficient::Apache::Request' );DESTROYING
Bficient::Apache::RequestThis doesn't look 'right', but I'm not
sure.Attached is my Bficient::Apache::Request object, If that
helps.Any help, or pointers would be greatly appreciated,kind
regardsMarty
#
#Module to sublass Apache to provide Custom Authorisation mechanisms
#Using the Apache::Session objects for each user.
#
package Bficient::Apache::Request;
use Bficient::Conf;
use lib qw(Bficient::Conf::PERL_LIB_DIR);
use Apache::Constants qw(OK REDIRECT SERVER_ERROR DECLINED FORBIDDEN);
use Apache::Cookie;
use Carp;
use Apache::Reload;
use Apache::Request;
use Bficient::Maketext;
use Data::Dumper;
use base 'Exporter';
use Bficient::DBI;
use Bficient::Apache::DBload qw($bdbh);
use MIME::Base64 qw(encode_base64 decode_base64);
use strict;
@Bficient::Apache::Request::ISA = qw(Apache::Request);
my $lh;
sub new
{
my ($class, $r) = @_;
#unless ($r)
#{
#print STDERR making a new Request object\n;
#$r = Apache::Request-new;
#}
my $self = bless {r = Apache::Request-new($r)}, $class;
my @params=$self-param();
print STDERR Here's the Parameters for $class\n;
print STDERR Dumper(@params);
my $lang_id=$self-param('lang_id');
if ($lang_id)
{
#print STDERR Using language_id of $lang_id\n;
$lh=Bficient::Maketext-get_handle($class,$lang_id);
}
else
{
#print STDERR Using Default language_id of
Bficient::Conf::DEFAULT_LANGUAGE_ID\nXX\n;
$lh=Bficient::Maketext-get_handle($class,Bficient::Conf::DEFAULT_LANGUAGE_ID);
}
#print STDERR Creating .ref($self).\n;
#$self-interpret_uri;
return $self;
}
sub DESTROY
{
my $self=shift;
print STDERR Dumper($self);
print STDERR DESTROYING .ref($self).\n;
#$self-SUPER-DESTROY();
}
sub current_db_id
{
my $self=shift;
my $db_id;
if($self-param('db_id'))
{
$db_id=$self-param('db_id');
die $self-lh-maketext(Empty database ID string Used in Parameters\n) unless
$db_id;
}
else
{
my $current_plugin=$self-current_plugin;
#print STDERR Dumper($current_plugin);
my $current_plugin_id=$current_plugin-id;
#print STDERR PluginID='$current_plugin_id'\n;
my
$database=Bficient::Database-new({_load_default_plugin_database=$current_plugin_id,dbh=$bdbh,lang_id=$self-lang_id});
$db_id=$database-id;
}
return $db_id;
}
#sub make_plugin_html
#{
#my $self=shift;
#my $tt_href=shift;
#
#my $html='';
#
#my $db_id=$self-current_db_id;
#
#my $tt_file = Bficient::Conf::FRAMEWORK_TOPBAR_TEMPLATE;
#$tt_file=~s/\/\//\//;
#my $template = Template-new(Bficient::Conf::TT2_CONFIG);
#my @[EMAIL PROTECTED]::Plugin-all({dbh=$bdbh})};
##print STDERR Dumper (@plugins);
#my @non_admin=();
#foreach my $plugin (@plugins)
#{
#if ($plugin-Name eq Bficient::Conf::ADMIN_PLUGIN_NAME )
#{
#$tt_href-{admin_plugin}=$plugin;
#}
#else
#{
#push @non_admin, $plugin;
#}
#}
#
#$tt_href-{r}=$self;
#$tt_href-[EMAIL PROTECTED];
#$tt_href-{plugin_count}=scalar(@non_admin);
#$tt_href-{current_uri}=$self-uri;;
#
##print STDERR tt_VARS=\n;
##print STDERR Dumper(%tt_vars);
#
#my $tt_out=$self-process_template($tt_file, $tt_href);
#
#return $tt_out;
#}
sub user_object
{
my $self=shift;
my $session_id=shift;
my $uh;
if ($uh)
{
my $un=$uh-UserName;
#print STDERR HERE IS MY UH for '$un'\n;
#print STDERR Dumper($uh);
print STDERR $lh-maketext(Using Previously Cached user_object
Apache::Request
I have read that the param Method had been deprecated
$r-param('value'):
How do I get now the variables from a submitted form ??
regards Ewald
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: the deprecation of Apache-request in mp2
Hello, NTI sure hope not! I second John Siracusa's post on this. Keep the HTML NTgeneration well away from request parsing, please! I personally am 100% in the camp of keeping HTML generation separate from quest parsing, but I do recognize the advantage of having API level compatibility between Apache::Request and CGI, so that you could switch from one to another easily. I think this would be a big win for mod_perl overall from the port your scripts quickly point of view. I think a good compromise would be to keep the HTML generation code in an entirely separate module, like Apache::Request::HTML or something. That class could augment Apache::Request with new methods. (This is somewhat similar to how Apache::File and Apache::Log augment the Apache class with new methods.) This seems to satisfy both sides, and accomplish the laudable goal of making CGI and Apache::Request API compatible without bloating up the normal use of Apache::Request. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: the deprecation of Apache-request in mp2
On Tue, 25 Mar 2003, Stas Bekman wrote:
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request-new($r);
$r = CGI-new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well.
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well
away from request parsing, please!
- nick
--
Nick Tonkin {|8^)
Re: the deprecation of Apache-request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: Lincoln Stein wrote: How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
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: 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: the deprecation of Apache-request in mp2
On 3/24/03 7:08 PM, Stas Bekman wrote: In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. I've always thought that HTML generation does not belong in CGI.pm, so I don't see duplicating that functionality in an extended $r as a useful goal. Better to separate the HTML stuff (preferably into HTML widget objects, IMO) from request parsing and response formulation and delivery. -John
Apache::Request: analyse output.
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.
Thanks.
aa29
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
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
Apache::Request incompatible with CGI ?
(Originally posted as Apache::Registry incompatible with CGI? by mistake
- sorry !)
Hi,
I have written a request handler in Perl. I recently changed some code
in this to convert
from using CGI within mod_perl to using Apache::Request. The old code
was ...
$DB-{ApacheReq} = shift;
:
$DB-{Page} = CGI::new();
:
The new code is ...
:
$DB-{ApacheReq}= Apache::Request-new(shift);
:
$DB-SetupPageArguments();
:
sub SetupPageArguments()
{
my ($DB, $nLoop, @Query, $Key, $Value);
$DB=shift;
@{$DB-{Page}-{'.parameters'}}=$DB-{ApacheReq}-param();
for($nLoop=0; $nLoop=$#{$DB-{Page}-{'.parameters'}}; $nLoop++)
{
if(!defined($DB-{ApacheReq}-param($DB-{Page}-{'.parameters'}[$nLoop]
)))
{
$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}[0]='';
}
else
{
@{$DB-{Page}-{$DB-{Page}-{'.parameters'}[$nLoop]}}=$DB-{ApacheReq}-
param($DB-{Page}-{'.parameters'}[$nLoop]);
}
}
}
My handler then referes to the '.parameters' field and the arrays of
values. For most posts
this works fine. However, when I send a large block of data in with the
request I have found
that portions of the middle are left out. Putting the old code back
means that the whole of the
text is seen.
I am using a client program written in C++ to send the requests in. All
requests are sent as a
multipart message, with each form field having one part within the
message. On the particular
instance I have been looking at the overall content size for the request
(excluding the header)
in my application is set to 21555. (I have not set the flag to limit
post size as you can see
from the above). The end of the request appears as follows (This request
happens to conatin
Javascript, but the content should be irrelevant as it has not been
processed by anything at
this stage) ...
:
:
:
function NewProductExtension(Id, ExtensionId, Description, MinRequired,
MaxRequired, Visible, WarnLessThan, WarnGreaterThan, LessThanWarning,
GreaterThanWarning, Width, Units)\n{\n new ProductExtension(Id,
ExtensionId, Description, MinRequired, MaxRequired, Visible,
WarnLessThan, WarnGreaterTha*ion CheckProductExtensions()
{
var nLoop;
var Rc=new String('');
for(nLoop=0; nLoopProducts.length; nLoop++)
{
if(Products[nLoop].ExtensionCountProducts[nLoop].Extensions.length)
{
Rc=Rc+(Products[nLoop].ProductId+',');
}
}
Rc=Rc.substr(0, Rc.length-1);
return(Rc);
}
where * denotes the portion that is missing (about 100 lines
or so)
I also sometimes see spurious data added after the request.
My server is running linux 2.4.18 on a two-way Intel box. I have Apache
1.3.26 / mod_perl 1.27
I downloaded Apache::Request from CPAN and I have version 0.31. My C
compiler is gcc 2.96
I have not been able to run a LAN trace to see what's being sent, but
since it is OK with CGI.pm I
assume that I am sending what my client says I'm sending.
Unfortunately I do not understand how the C / Perl and XS files all
stitch together so my attempts
to look at the code have not been fruitful.
I have adopted some code that works neatly under the Apache::Request but
will have to be fudged to
work with CGI so I am keen to get this working.
Can anyone help ?
Rob Lambden
Re: Apache::Request incompatible with CGI ?
I downloaded Apache::Request from CPAN and I have version 0.31. My C compiler is gcc 2.96 aiya. libapreq 0.31 is the one that likes to append whatever it is that one just uploaded to it to its heap until it starves your machine of memory, if i recall correctly. it was fixed in 0.31_03 i believe but it looks like 1.1 was released last week. .dorian
[mp2] Apache::Request
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Does anyone know when this module might be released? tia lee Lee Goddard mailto:[EMAIL PROTECTED] What do people like to drink here, then? The landlord looked sideways at his customers, a clever trick given that they were directly in front of him. - - Mort goes out for a drink (Terry Pratchett, Mort) -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPjqOSadrfekeF/QBAQFAxAQAhMyxXG/Tn/xoXY0+FzpAKBtuyymyQXz1 nnQXo3+nxopl6llRGTWF9gbi/euiqeQm2iHXx+ifgulbA2p3CJt2MKL/OsQ33Ygp M6tIRz9TvXdPIZGT/HGZ2ToPnO2c5O9EH5ZVmmMhnbWAmwJK+gBWAA6wgSVasLPX fFFRUWZKKRI= =Bpad -END PGP SIGNATURE-
Re: [mp2] Apache::Request
On Fri, 31 Jan 2003, Lee Goddard wrote:
Does anyone know when this module might be released?
No, no one does. They are working on it. Use CGI.pm instead or revert to
mod_perl/apache version 1 until it is done.
- nick
Nick Tonkin {|8^)
mp2.0 Apache::Request
Hi.
I use apache-1.3.26, modperl-1.27 and Embperl-1.3 with libapreq-1.0
and I have a routine in perl that processes the data passed from
a form (from the Modperl Cookbook):
use Apache::Request;
my $r = Apache::Request-instance(Apache-request);
foreach $param ($r-param)
{
.
}
In the documentation of nodperl-2.0, I cannot find any references to
libapreq and $r-param.
Does anybody know how I can process the data in modperl-2.0?
Thanks.
R. Amer
Polythecnic University of Catalonia
Re: mp2.0 Apache::Request
In the documentation of nodperl-2.0, I cannot find any references to libapreq and $r-param. correct me if I'm wrong anyone,but I don't think Apache::Request has been ported to modperl2 yet.. for now I'm using cgi
Re: mp2.0 Apache::Request
Steve wrote: In the documentation of nodperl-2.0, I cannot find any references to libapreq and $r-param. Because it's not there yet. correct me if I'm wrong anyone,but I don't think Apache::Request has been ported to modperl2 yet.. True. The C porting of libapreq is almost complete. The Perl glue will come next. (A few months?) for now I'm using cgi Steve probably means CGI.pm ;0) Though make sure that you use the latest version if you want to run it under mod_perl 2.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
Re: passing Apache::Request object
Marc Lambrichs wrote: Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization-get_request() method to use it again. perldoc Apache::Request: instance The instance() class method allows Apache::Request to be a singleton. This means that whenever you call Apache::Request-instance() within a single request you always get the same Apache::Request object back. This solves the problem with creating the Apache::Request object twice within the same request - the symptoms being that the second Apache::Request object will not contain the form parameters because they have already been read and parsed. my $apr = Apache::Request-instance($r, DISABLE_UPLOADS = 1); [... more in the manpage ...] __ 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
passing Apache::Request object
Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization-get_request() method to use it again. How can I do this in a safe manner? If you're wondering, why I would want to do this, take a look at Perrin Harkins perl.com article about etoys. Cheers, Marc
Re: Migrating from CGI.pm to Apache::Request question.
Jesse Erlbaum wrote: Hi Coexec -- I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? Speed. Apache::Request's guts are implemented in C, CGI.pm is Perl. If you do a lot of processing the speed improvement is significant. See: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Migrating from CGI.pm to Apache::Request question.
Hello all, I have been searching through the mailing list archives for the answer to my question, but I have not found it. I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. According to everything that I have been reading, the Apache::Request module handles only GET, POST and Cookie data, and no HTML. Basically, my question is, what is the most commonly used module for generating HTML like the CGI.pm does ? Thanks __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
Re: Migrating from CGI.pm to Apache::Request question.
On Tue, 19 Nov 2002, Coexec wrote: Date: Tue, 19 Nov 2002 15:40:37 -0800 (PST) From: Coexec [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Migrating from CGI.pm to Apache::Request question. Hello all, I have been searching through the mailing list archives for the answer to my question, but I have not found it. I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. According to everything that I have been reading, the Apache::Request module handles only GET, POST and Cookie data, and no HTML. Basically, my question is, what is the most commonly used module for generating HTML like the CGI.pm does ? Thanks There are so many different ways to handle HTML generation that it will make your head spin. You're always welcome to continue using CGI.pm's methods for generating HTML, but that usually couples the logic and presentation of your application so tightly that it makes for less-than-maintainable code -- less than what, however, remains the question. Many people like to use templating systems (HTML::Template, Template::Toolkit), some like to use more all-inclusive packages (Mason, Apache::ASP, Embperl), some people just use print statements (arguably the worst choice). Asking what is the most common way people on this list won't likely generate a consensus; ask 10 people how they do this and you'll probably get 10 different answers. As for me, I'm quite partial to Template::Toolkit. You'll have to decide what works best for you. No need to use a sledgehammer to drive a finishing nail. Use whatever tool is the simplest to use for your situation, but no simpler. :-) ky
RE: Migrating from CGI.pm to Apache::Request question.
Hi Coexec -- I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? If you're already using Apache::Registry, then your CGI.pm apps are ALREADY running as mod_perl modules. The move from CGI.pm to Apache::Request, in this case, is not likely to give you any real speed advantage. As you've pointed out, Apache::Request is only a partial replacement for CGI.pm. Ken suggested that you could continue to use CGI.pm in addition to Apache::Request if you need the functionality. If you choose to do so you will be using even MORE code than CGI.pm alone. More code means more memory, at very least -- not to mention the complexity of the system. Finally, you have to throw away all that time you spent learning the finer points of CGI.pm, and spend time learning the finer points of Apache::Request. Multiply that by the number of developers you have. I see that a few people have been doing this over the years, but I still don't see the advantage. Other than the Siren call of don't use CGI.pm -- it's evil, I can't imagine that Apache::Request has any really compelling advantages. Personally, I use CGI.pm (via CGI::Application) for my applications and straight mod_perl handlers for low-level functionality such as authentication, authorization and custom logging. This allows the majority of my developers, who are engaged in writing application code (the vast majority of the work on the typical project), to leverage their expertise. More advanced mod_perl hacks work on the heavy lifting handlers, which are few and far between. On a related topic, I strongly agree with Ken that you should move your HTML generation into a templating system. HTML::Template is my personal preference. I use H::T in conjunction with CGI::Application to implement all my web apps. FWIW, CGI::Application works equally well with Template Toolkit, if that's your preference. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
It's hard to generalize because in some cases the shared object file may actually not be installed. However, there should probably be something in the documentation that tells the user to make sure that the LD_LIBRARY_PATH variable and/or the /etc/ld.so.conf file include the usual default installation paths for required packages. -DeAngelo -Original Message- From: Perrin Harkins [mailto:perrin;elem.com] Sent: Friday, November 08, 2002 1:10 PM To: DeAngelo Lampkin Cc: mod_perl Mailing List Subject: Re: Can't locate object method new via package Apache::Request (via Mason)...SOLVED DeAngelo Lampkin wrote: And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). There is documentation related to this problem in the troubleshooting section, and if you'd like to generalize it a little so it will be easier for others to find when looking at this type of message, your help would be welcome. The current documentation is here: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#install_driver_Oracle__failed__Can_t_load__DBD_Oracle_Oracle_so__for_module_DBD__Oracle - Perrin
Apache::Request + Apache::Filter
List, Can anyone tell me if a module exists that combines these two modules so that, for example, when using Apache::Dispatch one can create an instance of Apache::Request in the handler without clobbering the overridden methods sent as part of the Apache::Filter object. Before I try and do this I wondered if it had already been done? Apache::RequestFilter would make sense to me but something like this doesn't seem to exist on CPAN. Ric
Re: Apache::Request + Apache::Filter
Hello,
We use this patch (on Apache::Filter 1.019) and it works ok. It won't
get you up and running with Apache::Registry, but it will do if you can
initialize the filter yourself.
Add this to Filter.pm:
sub Apache::Request::filter_register {
my $r= shift;
ISA = qw(Apache::Request);
Apache::filter_register ($r);
}
Here is the usage in your own code (this is slightly subtle):
my $old_r = Apache-request();
my $filtered_r = Apache::Request-instance($old_r)-filter_register();
That should do the trick. There is probably a cleaner way to do it, but
this has worked for us.
John
On Tuesday, November 12, 2002, at 02:22 PM, Richard Clarke wrote:
List,
Can anyone tell me if a module exists that combines these two
modules so
that, for example, when using Apache::Dispatch one can create an
instance of
Apache::Request in the handler without clobbering the overridden
methods
sent as part of the Apache::Filter object. Before I try and do this I
wondered if it had already been done? Apache::RequestFilter would make
sense
to me but something like this doesn't seem to exist on CPAN.
Ric
RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
Huh? It tells you EXACTLY what is wrong. No, not really. One reason is that it's not immediately clear (to me) which file can't be loaded. Is it Request.so or libapreq.so.1 that can't be loaded? This ambiguity is further blurred when you know both files are installed. And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). Searching the mailing list archives indicates that method name resolution is not exacly a new problem with mod_perl. Just ask this guy = http://lists.fsck.com/pipermail/rt-users/2002-September.txt. It's the exact same problem with the exact same error message, only in different clothing (he's having trouble with the Apache::Cookie object rather than the Apache::Request object). In the interest of full disclosure, other possible solutions include resetting /etc/ld.so.conf or the LD_LIBRARY_PATH variable to include more places to look for shared object files (only recently figured this out). But again, unless you're somewhat experienced or have encountered this class of bug before, this won't necessarily be the obvious place to look at first. Anyway enough of my babbling. Now that the answer is out there, hopefully it'll help out the poor souls who run into this issue in the future. Later, DeAngelo -Original Message- From: Ged Haywood [mailto:ged;www2.jubileegroup.co.uk] Sent: Thursday, November 07, 2002 10:01 PM To: DeAngelo Lampkin Cc: mod_perl Mailing List Subject: RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED Hi there, On Thu, 7 Nov 2002, DeAngelo Lampkin wrote: A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib) [snip] I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so'\ for module Apache::Request: libapreq.so.1: cannot open shared object file:\ No such file or directory [snip] This isn't the most helpful error message in the world. Huh? It tells you EXACTLY what is wrong. 73, Ged.
RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
Cool. Will do. -Original Message- From: Tim Tompkins [mailto:timt;arttoday.com] Sent: Thursday, November 07, 2002 12:27 PM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method new via package Apache::Request (via Mason)...SOLVED As a quick follow-up, the PerlModule Apache::Request line is NOT needed in the httpd.conf file for Mason to work. However, it was a very valuable debugging tool. That wasn't really the purpose, though. The purpose was to pre-load the module in the parent apache process for efficiency. My suggestion did come about because it appeared that Apache::Request wasn't being loaded at all. I'm not exacly sure how that happened as Mason's ApacheRequest attempts to require() Apache::Request a couple of places. But just the same, my suggestion to pre-load Apache::Request, as well as any other lib you normally use, stands. See: http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modul es_at_Server_Startup Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ --
Re: Can't locate object method new via package Apache::Request(via Mason)...SOLVED
DeAngelo Lampkin wrote: And of course the other reason is that if the solution to the problem was so obvious from the error message, somebody would have posted a solution before I figured it out (with help from you guys). There is documentation related to this problem in the troubleshooting section, and if you'd like to generalize it a little so it will be easier for others to find when looking at this type of message, your help would be welcome. The current documentation is here: http://perl.apache.org/docs/1.0/guide/troubleshooting.html#install_driver_Oracle__failed__Can_t_load__DBD_Oracle_Oracle_so__for_module_DBD__Oracle - Perrin
RE: Can't locate object method new via package Apache::Request (via Mason)...
You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method new via package Apache::Request (via Mason)... Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
RE: Can't locate object method new via package Apache::Request (via Mason)...
Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method new via package Apache::Request (via Mason)... Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
RE: Can't locate object method new via package Apache::Request (via Mason)...
What version of perl ?
Post 1.12 Mason has problems with perl 5.6.0 I believe ( or maybe .1 as
well )
You're quite right about the problem not necessarily being a mason one.
However as a mason user - you're likely to get help there all the same on
things that are border line mason ( the new Request object is created IN
ApacheHanler.pm )
Try this:
Change your httpd.conf to use a mason-handler.
Create a mason-handler.pl in either your @INC or your apache root.
I put mine in the later ( /etc/httpd/ on my system ).
Make sure the ownership / permissions of the mason-handler allow execution
( chmod +x if you must )
httpd.conf
-
PerlRequire mason-handler.pl
Directory /var/virtual/www.mason-site.com
FilesMatch \.(html|js|css)$
SetHandler perl-script
PerlHandler HTML::Mason
/FilesMatch
/Directory
mason-handler.pl
-
package HTML::Mason;
use HTML::Mason;
use HTML::Mason::ApacheHandler();
use strict;
my $ah = new HTML::Mason::ApacheHandler (
comp_root='/var/virtual/www.mason-site.com/'
data_dir='/var/virtual/HTML-Mason/data'
);
chown ( 99, 99, $ah-interp-files_written );
{
package HTML::Mason::Commands;
use HTML::Entities;
use vars qw($global1 $global2 $global3);
$_escape = sub { my $text = join '', @_;
HTML::Mason::Escapes::basic_html_escape(\$text); return $text }
}
1;
sub handler
{
my ($r) = @_;
return -1 if $r-content_type $r-content_type =~ m|^image/|i;
$ah-handle_request($r);
}
==
That's akin to what we use.
Obviously change the /var/virtual to whatever you use as your root - and
HTML-Mason is just where I wanted to keep our data for cache and stuff.
The $globals are just examples.
Once you've done this - let me know if you still get the same problem.
Remember to keep copies of all files you change.
I'd advice RCS/CVS ( i use the former ) for things like httpd.conf if you
want to keep it tidy.
Regards
Gareth
-Original Message-
From: DeAngelo Lampkin [mailto:dlampkin;xencor.com]
Sent: 07 November 2002 17:54
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Can't locate object method new via package
Apache::Request (via Mason)...
Hi Gareth,
I'm using the latest version of Mason, Mason 1.15. As I posted in my
previous email, I put the following lines into my httpd.conf file per the
instructions on Mason's website:
PerlModule HTML::Mason::ApacheHandler
FilesMatch \.msn$
SetHandler perl-script
PerlHandler HTML::Mason::ApacheHandler
/FilesMatch
The reason this wasn't posted on a Mason mailing list is that this didn't
seem like a Mason problem per se and the Mason mailing list page
specifically mentioned the Apache Request object (at least in part the
source of my problem)as being something that is not directly Mason
related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I
took the advice of the list moderator and posted on the mod_perl list
instead.
Thanks!
DeAngelo
-Original Message-
From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com]
Sent: Thursday, November 07, 2002 1:44 AM
To: DeAngelo Lampkin; [EMAIL PROTECTED]
Subject: RE: Can't locate object method new via package
Apache::Request (via Mason)...
You need to set Mason up better - probably.
I'm an avid Mason user, and I've seen this a fair few times.
If you want help, you're most likely to get it on the
[EMAIL PROTECTED] list.
However if you want to tell me the version of mason you're using it might
help.
You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new
Lexer / Compiller components.
There should be a require statement in your httpd.conf.
This gives you better control over data structures, variable scopes, and an
opportunity to handle persistent database connections better in the handler.
Check out the information on http://www.masonhq.com
Hope this helps.
Gareth
-Original Message-
From: DeAngelo Lampkin [mailto:dlampkin;xencor.com]
Sent: 06 November 2002 23:25
To: [EMAIL PROTECTED]
Subject: Can't locate object method new via package Apache::Request
(via Mason)...
Hey guys,
You may remember me from such messages as I can't get mod_perl to compile
on Irix64 systems!. Well now I've got a whole new problem that I need your
expertise on.
I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However,
whenever I go to a page that should be handled by Mason (a perl templating
system), I get the following error message:
[Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via
package Apache::Request at
/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878.
My guess
Re: Can't locate object method new via package Apache::Request (via Mason)...
Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: DeAngelo Lampkin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method new via package Apache::Request (via Mason)... Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
Re: Can't locate object method new via package Apache::Request (via Mason)...
You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: Tim Tompkins [EMAIL PROTECTED] To: DeAngelo Lampkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: DeAngelo Lampkin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method new via package Apache::Request (via Mason)... Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
RE: Can't locate object method new via package Apache::Request (via Mason)...
Tim - Did you not get the 18:06 email of mine ? It uses a handler instead. So he wouldn't be using this method anyway - if he decided to follow my suggestion. By the way - i'm new to this list - :-) Gareth -Original Message- From: Tim Tompkins [mailto:timt;arttoday.com] Sent: 07 November 2002 18:16 To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: Tim Tompkins [EMAIL PROTECTED] To: DeAngelo Lampkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: DeAngelo Lampkin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message- From: DeAngelo Lampkin [mailto:dlampkin;xencor.com] Sent: 06 November 2002 23:25 To: [EMAIL PROTECTED] Subject: Can't locate object method new via package Apache::Request (via Mason)... Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some
Re: Can't locate object method new via package Apache::Request (via Mason)...
Sure I did. I was just keeping my response to the context of his present configuration according to the sample he sent. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: Gareth Kirwan [EMAIL PROTECTED] To: Tim Tompkins [EMAIL PROTECTED]; DeAngelo Lampkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:20 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Tim - Did you not get the 18:06 email of mine ? It uses a handler instead. So he wouldn't be using this method anyway - if he decided to follow my suggestion. By the way - i'm new to this list - :-) Gareth
RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
Thanks to Tim, Gareth, and Phillippe: OK, I'll start with the solution to the problem and then drag on a bit for how I found it. The problem was the location of a shared object file for the Apache Request object. A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib), which was ok for the test script that Phillippe gave me and the one-liner that Gareth gave me, but was apparently NOT ok for Mason in the context of mod_perl. I didn't figure this out until I tried Tim's suggestion of preloading the Apache::Request module inside of httpd.conf. I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. This isn't the most helpful error message in the world. However, I knew Request.so and libapreq.so.1 were installed, but I didn't know if they were in places that the server process expected them to be. So did a search for all the shared object files and noticed libapreq.so.1 file was sitting all by itself in /usr/local/lib, while about a billion other shared object files were inside of /usr/lib. I moved libapreq.so.1 to the place where all the other cool shared object files hung out, crossed my fingers, and booya! It worked. Apprently something about the way I configured the installation for libapreq was not very Mason friendly. Anyway, thanks again for the help. DeAngelo -Original Message- From: Tim Tompkins [mailto:timt;arttoday.com] Sent: Thursday, November 07, 2002 10:16 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: Tim Tompkins [EMAIL PROTECTED] To: DeAngelo Lampkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: DeAngelo Lampkin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl with Mason 1.12 ( or 1.15) and the new Lexer / Compiller components. There should be a require statement in your httpd.conf. This gives you better control over data structures, variable scopes, and an opportunity to handle persistent database connections better in the handler. Check out the information on http://www.masonhq.com Hope this helps. Gareth -Original Message
RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
As a quick follow-up, the PerlModule Apache::Request line is NOT needed in the httpd.conf file for Mason to work. However, it was a very valuable debugging tool. -Original Message- From: DeAngelo Lampkin Sent: Thursday, November 07, 2002 11:21 AM To: Tim Tompkins; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)...SOLVED Thanks to Tim, Gareth, and Phillippe: OK, I'll start with the solution to the problem and then drag on a bit for how I found it. The problem was the location of a shared object file for the Apache Request object. A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib), which was ok for the test script that Phillippe gave me and the one-liner that Gareth gave me, but was apparently NOT ok for Mason in the context of mod_perl. I didn't figure this out until I tried Tim's suggestion of preloading the Apache::Request module inside of httpd.conf. I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. This isn't the most helpful error message in the world. However, I knew Request.so and libapreq.so.1 were installed, but I didn't know if they were in places that the server process expected them to be. So did a search for all the shared object files and noticed libapreq.so.1 file was sitting all by itself in /usr/local/lib, while about a billion other shared object files were inside of /usr/lib. I moved libapreq.so.1 to the place where all the other cool shared object files hung out, crossed my fingers, and booya! It worked. Apprently something about the way I configured the installation for libapreq was not very Mason friendly. Anyway, thanks again for the help. DeAngelo -Original Message- From: Tim Tompkins [mailto:timt;arttoday.com] Sent: Thursday, November 07, 2002 10:16 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... You should pre-load Apache::Request anyway, PerlModule Apache::Request PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: Tim Tompkins [EMAIL PROTECTED] To: DeAngelo Lampkin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 11:08 AM Subject: Re: Can't locate object method new via package Apache::Request (via Mason)... Is Apache::Request installed for perl 5.8.0? Sounds like it's not loaded, anyway. Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ -- - Original Message - From: DeAngelo Lampkin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 10:54 AM Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... Hi Gareth, I'm using the latest version of Mason, Mason 1.15. As I posted in my previous email, I put the following lines into my httpd.conf file per the instructions on Mason's website: PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch The reason this wasn't posted on a Mason mailing list is that this didn't seem like a Mason problem per se and the Mason mailing list page specifically mentioned the Apache Request object (at least in part the source of my problem)as being something that is not directly Mason related( http://lists.sourceforge.net/lists/listinfo/mason-users ). So I took the advice of the list moderator and posted on the mod_perl list instead. Thanks! DeAngelo -Original Message- From: Gareth Kirwan [mailto:gbjk;thermeoneurope.com] Sent: Thursday, November 07, 2002 1:44 AM To: DeAngelo Lampkin; [EMAIL PROTECTED] Subject: RE: Can't locate object method new via package Apache::Request (via Mason)... You need to set Mason up better - probably. I'm an avid Mason user, and I've seen this a fair few times. If you want help, you're most likely to get it on the [EMAIL PROTECTED] list. However if you want to tell me the version of mason you're using it might help. You could use a mason-handler.pl
Re: Can't locate object method new via package Apache::Request (via Mason)...SOLVED
As a quick follow-up, the PerlModule Apache::Request line is NOT needed in the httpd.conf file for Mason to work. However, it was a very valuable debugging tool. That wasn't really the purpose, though. The purpose was to pre-load the module in the parent apache process for efficiency. My suggestion did come about because it appeared that Apache::Request wasn't being loaded at all. I'm not exacly sure how that happened as Mason's ApacheRequest attempts to require() Apache::Request a couple of places. But just the same, my suggestion to pre-load Apache::Request, as well as any other lib you normally use, stands. See: http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modul es_at_Server_Startup Regards, Tim Tompkins -- Programmer http://www.clipart.com/ http://www.rebelartist.com/ --
RE: Can't locate object method new via package Apache::Request(via Mason)...SOLVED
Hi there, On Thu, 7 Nov 2002, DeAngelo Lampkin wrote: A file called libapreq.so.1 was located in /usr/local/lib (should have been in /usr/lib) [snip] I ended up getting this thing: Syntax error on line 362 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so'\ for module Apache::Request: libapreq.so.1: cannot open shared object file:\ No such file or directory [snip] This isn't the most helpful error message in the world. Huh? It tells you EXACTLY what is wrong. 73, Ged.
Can't locate object method new via package Apache::Request (via Mason)...
Hey guys, You may remember me from such messages as I can't get mod_perl to compile on Irix64 systems!. Well now I've got a whole new problem that I need your expertise on. I'm running Apache 1.3x and mod_perl 1.2x on a Linux system. However, whenever I go to a page that should be handled by Mason (a perl templating system), I get the following error message: [Wed Nov 6 11:56:20 2002] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/ApacheHandler.pm line 878. My guess is that this (at some level)involves a configuration error of some kind. I added the following lines to my httpd.conf file per the instructions on Mason's website: --- PerlModule HTML::Mason::ApacheHandler FilesMatch \.msn$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /FilesMatch - So I'm not sure what's going on here. I looked through Apache/Request.pm and found no new method and I didn't find one inside of Apache.pm either (from which the Request module inherets). However, I'm assuming this is all correct and some magical ultra-Perl-guru AUTOLOAD-like functionality is going on somewhere. Does anyone have any ideas about what may be causing this? Thanks, DeAngelo
Re: Can't locate object method new via package Apache::Request (via Mason)...
Seems somewhat similar to a bug I've reported 10 months ago.
You might want to try to run the minimal testcase enclosed in the
forwarded mail.
Phil.
---BeginMessage---
I've found that mod_perl can get confused when dealing with method
calls during a redirect_internal phase:
1. page /1 uses method calls, and works when accessed as /1
2. an other page /R uses internal_redirect to go to /1, and mod_perl
fails with an undefined subroutine error.
This has been seen on:
apache 1.3.9-14, perl 5.004.05-1.1, and mod_perl 1.25-3 (Debian potato)
and on:
apache 1.3.22-2.1, perl 5.6.1-6, and mod_perl 1.26-1 (Debian woody/testing)
How to reproduce:
Use this startup.pl file:
==
# Common
package Common;
use Apache::Constants qw(:common);
sub handler($$)
{
my $self = shift;
my $req = shift;
$req-content_type('text/plain');
$req-send_http_header();
$req-print($self-doit());
return OK;
}
sub doit
{
return COMMON;
}
# Common::Impl1
package Common::Impl1;
ISA=qw(Common);
sub doit
{
return IMPL1\n;
}
# Common::Impl2;
package Common::Impl2;
ISA=qw(Common);
sub doit
{
return IMPL2\n;
}
# Redir
package Redir;
use Apache::Constants qw(:common);
sub handler
{
my $req = shift;
$req-internal_redirect(/1);
return OK;
}
1;
==
PerlRequire the above, and use the following apache configuration:
==
Location /0
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common
/Location
Location /1
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl1
/Location
Location /2
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl2
/Location
Location /R
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Redir
/Location
PerlRequire startup.pl
==
Then, directing a web browser to /0 prints COMMON, to /1 prints IMPL1,
to /2 prints IMPL2, as expectected.
Similarly, when pointing to /R (which redirects internally to /1),
IMPL1 should appear.
However, I get a 500 Internal server error and this in the logs:
[error] Undefined subroutine Common::Impl1::handler called at
startup.pl line 49.
I've tried to debug the problem, and the problem lies inside
perl_handler_ismethod() in src/modules/perl/mod_perl.c: it returns
different values when called from inside the internal_redirect than
called without internal_redirect.
Inside perl_handler_ismethod():
if(!sub) return 0;
sv = newSVpv(sub,0);
if(!(cv = sv_2cv(sv, stash, gv, FALSE))) {
GV *gvp = gv_fetchmethod(pclass, sub);
if (gvp) cv = GvCV(gvp);
sv_2cv() returns different values when called from inside an
internal_redirect than called without
internal_redirect. Unfortunately, I could not grok sv_2cv(). It's not
even documented in the perl docs.
Phil.
---End Message---
newbie:How to get form input in mod_perl 2 since Apache::request is not implemented yet ?
Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Thanks in advance. Sumitro Chowdhury.Do you Yahoo!? HotJobs - Search new jobs daily now
Re: UTF8 character issue with Apache::Request?
Confirmed, but its browser dependant. IE on Mac OS X sends the file but munges the filename. So they file arrives fine but with the wrong name. Mozilla on Mac OS X doesnt even send the file. Still waiting for results with windows systems buth Eng and J. John- On 28 Sep 2002 23:02:59 -0400 Joe Schaefer [EMAIL PROTECTED] wrote: Peter Bi [EMAIL PROTECTED] writes: Please take a serious look. I did, and I suspect this problem is caused by OP's client/browser failing to open the file with the Kanji filename, so it might be sending an empty file with the default enctype instead. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. You seem to know something about this issue. However, this is the first time I've seen utf8 discussed in relation to Apache::Request on this list. I've tried a few dozen links from google (utf8 Apache::Request), and I've searched the epigone archives for this list. I wasn't able to find a single related report. A reference url, a test case, or a better still, a patch, would be considerably more helpful than sending me on a wild goose chase. -- Joe Schaefer
Re: UTF8 character issue with Apache::Request?
[EMAIL PROTECTED] writes: [...] With Kanji filename : Size is 0 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=.DOC UPL:Content-Type=application/octet-stream Without Kanji filename Size is 306688 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=copy.DOC UPL:Content-Type=application/msword Any thoughts or input would be great. Are you certain this is a server-side problem? The varying Content-Types look suspicious to me. I'd double-check (via tcpdump or something) that the client is actually sending the whole file to the server. -- Joe Schaefer
Re: UTF8 character issue with Apache::Request?
Please take a serious look. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. Peter - Original Message - From: Joe Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Saturday, September 28, 2002 10:08 AM Subject: Re: UTF8 character issue with Apache::Request? [EMAIL PROTECTED] writes: [...] With Kanji filename : Size is 0 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=.DOC UPL:Content-Type=application/octet-stream Without Kanji filename Size is 306688 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=copy.DOC UPL:Content-Type=application/msword Any thoughts or input would be great. Are you certain this is a server-side problem? The varying Content-Types look suspicious to me. I'd double-check (via tcpdump or something) that the client is actually sending the whole file to the server. -- Joe Schaefer
Re: UTF8 character issue with Apache::Request?
Peter Bi [EMAIL PROTECTED] writes: Please take a serious look. I did, and I suspect this problem is caused by OP's client/browser failing to open the file with the Kanji filename, so it might be sending an empty file with the default enctype instead. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. You seem to know something about this issue. However, this is the first time I've seen utf8 discussed in relation to Apache::Request on this list. I've tried a few dozen links from google (utf8 Apache::Request), and I've searched the epigone archives for this list. I wasn't able to find a single related report. A reference url, a test case, or a better still, a patch, would be considerably more helpful than sending me on a wild goose chase. -- Joe Schaefer
UTF8 character issue with Apache::Request?
Hi All-
We are using Apache::Request to handle our uploads
via the browser. Now that we switched to UTF-8 encoding
any filename with Kanji in the filename uploads with a
size of '0' and nothing goes to disk. Take the same file,
put its name to roman chars and it uploads fine. All other
file fields handle Kanji inputs without any problems, only
TYPE=FILE bomb under Apache::Request.
Has anyone else seen a problem with Apache::Request
and kanji character filenames?
#
# Read and Encode the uploaded document
#
my $upload = $r-upload() ;
my $fh = $upload-fh() ;
my $info = $upload-info;
my $size = $upload-size;
$Title = $upload-filename ;
print STDERR Size is $size\n if $debug ;
if( $debug ) {
while (my($key, $val) = each %$info) {
print STDERR UPL:$key=$val\n ;
}
}
while( $buf = $fh ) {
$TEMP .= $buf ;
}
With Kanji filename :
Size is 0
UPL:Content-Disposition=form-data; name=UPLOADFILE;
filename=.DOC
UPL:Content-Type=application/octet-stream
Without Kanji filename
Size is 306688
UPL:Content-Disposition=form-data; name=UPLOADFILE;
filename=copy.DOC
UPL:Content-Type=application/msword
Any thoughts or input would be great.
John-
Re: Apache::Request
On Mon, 26 Aug 2002, Ufuk Yuzereroglu wrote: I dont know if this is the right place to ask but I just cant install Apache::Request. When calling 'make', make cant find any of the header files. Can anyone tell me where I did go wrong? Did you install mod_perl and apache successfully on the same machine? -- best regards, randy kobes
Apache::Request
Hi, I dont know if this is the right place to ask but I just cant install Apache::Request. When calling 'make', make cant find any of the header files. Can anyone tell me where I did go wrong? Thanks UY
Perl sections and Apache-request-subprocess_env
I'd like to access the original Apache startup environment variables from within Perl> sections. Through experimentation and reading page 498 of the Eagle that I need to use Apache->Request->subprocess_env to access the original environment in order to do this, as %ENV is cleared at interpreter creation. However, I cannot figure out how to do this in Perl> sections! Apache->Request returns undef (reasonably so, as there is no current request) So, the question is this: How to get the equivalent of $r->subprocess_env from within a Perl> section? -- -- Tom Mornini -- InfoMania Printing Prepress -- -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
Re: leaks with Apache::Request?
Joe Schaefer [EMAIL PROTECTED] writes:
[...]
Somehow the assignment operator MUST be involved in the leak here.
(You only get a leak when the *same* reference (*SV) is on both sides
of the assignment).
Could someone with modperl 1.2x built using a perl 5.8 release candidate
please test this out:
Perl
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache:Request;
package Apache::test;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
My error log for a request to /test is below. The above
assignment on the line marked XXX is modifying $apr, which
it shouldn't.
I don't have a 5.8-RC handy to test this on, but if somebody
else sees the same problem on 5.8, I'll file a bug report to p5p.
Thanks alot.
--
SV = RV(0x814b154) at 0x82309b8
REFCNT = 1
FLAGS = (ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472dc
SV = PVMG(0x8244f30) at 0x82472dc
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 136628428
NV = 0
PV = 0
STASH = 0x81420e4 Apache
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
SV = RV(0x814b154) at 0x82309b8
REFCNT = 1
FLAGS = (ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472f4
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
Dead: Apache=SCALAR(0x82472dc)
--
--
Joe Schaefer
Re: leaks with Apache::Request?
Joe Schaefer wrote: Somehow the assignment operator MUST be involved in the leak here. (You only get a leak when the *same* reference (*SV) is on both sides of the assignment). Could someone with modperl 1.2x built using a perl 5.8 release candidate please test this out: I got the same behavior (Apache/1.3.26 (Unix) mod_perl/1.27 perl@17440) with a modified version of your code (it doesn't work as is.) HTH.
Re: leaks with Apache::Request?
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache::Request;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
-- server error log for request to /test --
[Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix)
mod_perl/1.27_01-dev Perl/v5.8.0 configured
[...]
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626c78
SV = PVMG(0x8703110) at 0x8626c78
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 148451868
NV = 0
PV = 0
STASH = 0x8298510 Apache
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
Dead: Apache=SCALAR(0x8626c78)
Re: leaks with Apache::Request?
[resent to modperl list; earlier copy mistakenly cc'd to p5p]
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache::Request;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
-- server error log for request to /test --
[Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix)
mod_perl/1.27_01-dev Perl/v5.8.0 configured
[...]
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626c78
SV = PVMG(0x8703110) at 0x8626c78
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 148451868
NV = 0
PV = 0
STASH = 0x8298510 Apache
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
Dead: Apache=SCALAR(0x8626c78)
Re: leaks with Apache::Request?
On 8 Jul 2002, Joe Schaefer wrote: Write that like this, and I think your leak will disappear: my $r = Apache::Request-new( shift ); AFAICT, Apache::Request::new is NOT leaking here, since the REFCNT of its returned object IS 1. There might be some magic-related bug in perl that causes the assignment to bump $r's refcount to 2. This MIGHT be circumventable with some better code in Request.xs, but I really don't know how to fix it. Until some perl guru enlightens us, as a personal rule I try hard to avoid expressions like $foo = make_something_out_of($foo); I realize that this isn't always possible, but it often/usually is. Such advice would serve you well in this case; you could even get away with this my $r = shift; my $apr = Apache::Request-new($r); That's not going to leak, either. At least I hope not :-) I ended up using something like this and the leak went away. It seems to me that this might actually be a Perl bug. If I do this: my $x = shift; $x = make_something_from($x); then it seems like the original $x should go out of scope when it is assigned to, so its refcount should stay at 1. -dave /*== www.urth.org we await the New Sun ==*/
Re: leaks with Apache::Request?
Dave Rolsky [EMAIL PROTECTED] writes: On 8 Jul 2002, Joe Schaefer wrote: [...] my $r = shift; my $apr = Apache::Request-new($r); That's not going to leak, either. At least I hope not :-) I ended up using something like this and the leak went away. It seems to me that this might actually be a Perl bug. I doubt it's solely perl's fault. The problem is that you have to be an internals wizard to write safe XS; otherwise you just keep your fingers crossed. :-) Hopefully some generous soul will post a patch to Request.xs that prevents this problem from ever arising. If I do this: my $x = shift; $x = make_something_from($x); then it seems like the original $x should go out of scope when it is assigned to, so its refcount should stay at 1. ^^ Right, it should stay at 1. But all bets are off when $x is has magic and make_something_from() is an XS sub :-). -- Joe Schaefer
Re: leaks with Apache::Request?
* Joe Schaefer [EMAIL PROTECTED] [2002-07-09 12:47]: Dave Rolsky [EMAIL PROTECTED] writes: On 8 Jul 2002, Joe Schaefer wrote: If I do this: my $x = shift; $x = make_something_from($x); then it seems like the original $x should go out of scope when it is assigned to, so its refcount should stay at 1. ^^ Right, it should stay at 1. But all bets are off when $x is has magic and make_something_from() is an XS sub :-). But the leak is not with $x, it's with what $_[0] is; $x is just a reference to that, and the reassignment in the second line should reassign $x, and decrement the ref count for what $x is pointing to at that point. So, it all depends on what make_something_from() does with the $x's referent. (darren) -- Great minds discuss ideas. Average minds discuss events. Small minds discuss people. -- Admiral Hyman G. Rickover
Re: leaks with Apache::Request?
darren chamberlain [EMAIL PROTECTED] writes: * Joe Schaefer [EMAIL PROTECTED] [2002-07-09 12:47]: Dave Rolsky [EMAIL PROTECTED] writes: On 8 Jul 2002, Joe Schaefer wrote: If I do this: my $x = shift; $x = make_something_from($x); then it seems like the original $x should go out of scope when it is assigned to, so its refcount should stay at 1. ^^ Right, it should stay at 1. But all bets are off when $x is has magic and make_something_from() is an XS sub :-). But the leak is not with $x, it's with what $_[0] is; $x is just a reference to that, and the reassignment in the second line should reassign $x, and decrement the ref count for what $x is pointing to at that point. So, it all depends on what make_something_from() does with the $x's referent. I don't think it's as simple as that- THIS LEAKS: my $r = shift; $r = Apache::Request-new($r); my $r = shift; $r = Apache::Request-new($_) for $r; DOES NOT LEAK: my $apr = Apache::Request-new(shift); my $r = shift; my $apr = $r; # $r and $apr have the same referent now right? $apr = Apache::Request-new($r); my $r = shift; my $apr = Apache::Request-new($r); my $r = shift; $r = Apache::Request-new($_) for map $_, $r; Somehow the assignment operator MUST be involved in the leak here. (You only get a leak when the *same* reference (*SV) is on both sides of the assignment). -- Joe Schaefer
leaks with Apache::Request?
It looks like there may be a memory leak with Apache::Request. I'm using
version 1.0 with Perl 5.6.1, mod_perl 1.26, and Apache 1.3.26. mod_perl
is statically compiled into Apache.
Here's some code that I think demonstrates the leak:
package My::APRTest;
use strict;
use Apache::Request;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub handler
{
my $r = shift;
$r = Apache::Request-new($r);
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
When I run this, the DESTROY method is not called until the server shuts
down.
Watching memory using with top (against a server running as httpd -X) I
can see that memory usage is growing a little less the 500K every 5000
requests.
This isn't catastrophic but fixing it would be a good thing.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: leaks with Apache::Request?
Dave,
Perhaps this is why from the eagle book,
During the child exit phase, mod_perl invokes the Perl API function
perl_destruct( ) to run the contents of END blocks and to invoke the
DESTROY method for any global objects that have not gone out of scope
already.
So I think i'm right in saying that, When I run this, the DESTROY
method is not called until the server shuts down. is perfectly normal
behaviour. I don't know how you are actually testing your memory
usage, but I might suggest that if you are sending larger amounts of
data than previously, just once per 5000 requests then this memory is
gonna be consumed by apache forever (at least until httpd is killed).
Richard
Dave Rolsky wrote:
It looks like there may be a memory leak with Apache::Request. I'm using
version 1.0 with Perl 5.6.1, mod_perl 1.26, and Apache 1.3.26. mod_perl
is statically compiled into Apache.
Here's some code that I think demonstrates the leak:
package My::APRTest;
use strict;
use Apache::Request;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub handler
{
my $r = shift;
$r = Apache::Request-new($r);
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
When I run this, the DESTROY method is not called until the server shuts
down.
Watching memory using with top (against a server running as httpd -X) I
can see that memory usage is growing a little less the 500K every 5000
requests.
This isn't catastrophic but fixing it would be a good thing.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: leaks with Apache::Request?
On Mon, 8 Jul 2002, Richard Clarke wrote: During the child exit phase, mod_perl invokes the Perl API function perl_destruct( ) to run the contents of END blocks and to invoke the DESTROY method for any global objects that have not gone out of scope already. Notice where it says ... for any global objects that have not gone out of scope already. In the code I posted, $r goes out of scope at the end of the handler subroutine. So I think i'm right in saying that, When I run this, the DESTROY method is not called until the server shuts down. is perfectly normal behaviour. I don't know how you are actually testing your memory Well, creating an Apache::DESTROY method works and shows the Apache object going out of scope on a per-request basis. usage, but I might suggest that if you are sending larger amounts of data than previously, just once per 5000 requests then this memory is gonna be consumed by apache forever (at least until httpd is killed). I tested with ab sending the same request thousands of times in a row. -dave /*== www.urth.org we await the New Sun ==*/
Re: leaks with Apache::Request?
Dave Rolsky [EMAIL PROTECTED] writes:
[...]
Here's some code that I think demonstrates the leak:
package My::APRTest;
use strict;
use Apache::Request;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub handler
{
my $r = shift;
$r = Apache::Request-new($r);
^
Write that like this, and I think your leak will
disappear:
my $r = Apache::Request-new( shift );
AFAICT, Apache::Request::new is NOT leaking here, since the
REFCNT of its returned object IS 1. There might be some
magic-related bug in perl that causes the assignment to bump
$r's refcount to 2. This MIGHT be circumventable with some better
code in Request.xs, but I really don't know how to fix it.
Until some perl guru enlightens us, as a personal rule I
try hard to avoid expressions like
$foo = make_something_out_of($foo);
I realize that this isn't always possible, but it often/usually
is. Such advice would serve you well in this case; you could
even get away with this
my $r = shift;
my $apr = Apache::Request-new($r);
That's not going to leak, either. At least I hope not :-)
HTH
--
Joe Schaefer
Apache::Request $apr-param; problems.
I have a subrouting which returns references to
%r_info, %r_headers_hash and r_headers_list.
Part of %r_info is params from Apache::Request opbject $arq.
my %params;
foreach ($apr-param) {
$params{$_} = $apr-param{$_);
}
$r_info{'params'} = \%params,
however if this routine is called more than once with the same $r object
then the second time there are no params. It's as if calling $apr-param
strips them off $r. That's not clever. I can't find anything in the
documentation that says it would behave like that.
Any advice?
Kind Regards,
Wes
Rev. FPCED(UK)
y n=-09hu6+40563
2136+-*+96,
3.-/n*+963.h
