Re: Basic authentication
Stephen Hardisty wrote:
Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more applications to upgrade than time.
Any help/questions would be appreciated. The problem script is below:
use strict;
use Apache::Const qw(OK AUTH_REQUIRED);
use lib qw(/var/www/html/opbms/libs);
use CheckLogin;
use CreateFrames;
my $r = shift;
print Content-Type:text/html\n\n;
don't do that - AUTH_REQUIRED is an error status, so apache will send it's
own set of headers.
my ($status, $password) = $r-get_basic_auth_pw;
if ($status != OK)
{
$r-status($status);
exit($status);
}
yike!
you shouldn't ever play with $r-status. calling exit is also not the
standard way.
examples of auth handlers abound, so you should really just be following
them - even though you are using mod_perl 2.0, the API is really the same
wrt get_basic_auth_pw() etc.
some examples include the many, many modules on CPAN. you can also find
detailed auth examples in
http://www.modperlcookbook.org/chapters/ch13.pdf
and
http://www.modperlcookbook.org/code/ch13/
specifically
http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm
HTH
--Geoff
[ANNOUNCE] Apache::IncludeHook
hi all...
I wanted to let everyone know that I have ported !-- #perl -- SSI tag
support to Apache 2.0. it should behave under both prefork and threaded
mpms, and work pretty much the same as it did in Apache 1.3, despite the
fact that mod_include is now an output filter.
while the support is fairly complete, the code is a bit messy and can be
refactored. however, I wanted to get something released for people to play
with before I needed to move on to something else.
--Geoff
The URL
http://www.modperlcookbook.org/~geoff/modules/Apache-IncludeHook-2.00_01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GE/GEOFF/Apache-IncludeHook-2.00_01.tar.gz
size: 7289 bytes
md5: 0753eda141bf886290fa872fbffaf580
from the README:
NAME
Apache::IncludeHook - #perl Server Side Include support
SYNOPSIS
PerlModule Apache::IncludeHook
Alias /ssi /usr/local/apache/htdocs
Location /ssi
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Options +Includes
/Location
DESCRIPTION
Apache::IncludeHook offers support for #perl tags in
documents parsed by the mod_include engine included in
the Apache 2.0 distribution. Supported formats include
!--#perl sub=My::PrintArgs --
!--#perl arg=fee sub=My::PrintArgs arg=fie --
!--#perl arg=foe sub=My::PrintArgs::handler --
!--#perl arg=fum sub=My::PrintArgs-method_handler -- here
!--#perl arg=I smell sub=sub { my $r = shift; print @_ } --
In Apache 1.3, mod_include supported #perl tags out of
the box. In 2.0, support for tags outside the standard
mod_include realm ('echo', 'flastmod', etc) have been removed,
having been replaced with an API that allows you to hook
your own functionality into mod_include's parsing engine.
The 'exec' tag is an example of one that is no longer natively
supported by mod_include - mod_cgi now supplies the base
implementaiton of this tag.
The current hope with this module is simply to carry over #perl tag
support from Apache 1.3 to 2.0. Apache::SSI-like support
for custom tags will (possibly come later). keep in mind
that while this module is not inteneded to replace the old
Apache::SSI for Apache 1.3, because the new Apache 2.0 API
includes a filtering mechansim,
you already have the ability to post-process SSI tags via
Perl (or C) output filters.
EXAMPLE
file.shtml:
perl !--#perl arg=one sub=My::PrintArgs -- here
PrintArgs.pm:
package My::PrintArgs;
use Apache::RequestRec ();
use Apache::Const -compile = 'OK';
use strict;
sub handler {
my ($r, @args) = @_;
print join ' ', '***', (join ' : ', @args), '***';
return Apache::OK;
}
which is almost identical to what you would see with mod_perl 1.0,
save the mod_perl 2.0 specific classes.
NOTES
This implementation is designed to hook into the mod_include
that ships with Apache 2.0. It will not work with Apache 2.1.
This is alpha ware, subject to massive API changes. Meaning,
the TIEHANDLE interface may go away and you may be forced to
use only the (currently non-existent) filter interface. so
get to know filters now before it's too late (they're really
cool anyway).
FEATURES/BUGS
Subrequests are still a work in progress - they still don't seem
to work properly from filters.
only print STDOUT and $r-print are supported. other methods
of sending content to the client still need to be implemented.
AUTHOR
Geoffrey Young Elt[EMAIL PROTECTED]gt
COPYRIGHT
Copyright (c) 2003, Geoffrey Young
All rights reserved.
This module is free software. It may be used, redistributed
and/or modified under the same terms as Perl itself.
Re: Custom Log files Under MP2
Tofu Optimist wrote: Specifically, I'd like to log certain image file requests (all files with .jpg, .gif, and .png extensions) to a custom log, image_log, logging IP, file, time, status, bytes, referer, cookies, etc. I care about speed here. Would you suggest a native logging http://www.modperlcookbook.org/chapters/ch16.pdf or take this route http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler native Apache routines, written in C, will always be faster, so if you can get the same functionality from native routines use them. it's the flexibility mod_perl offers that makes it special :) If the former, would you have any sample config code to illustrate? I think the conditional logging recipe is pretty descriptive. see also the CustomLog directive description in the apache documentation http://httpd.apache.org/docs-2.0/mod/directives.html FilesMatch might also help. --Geoff Thanks! -TO --- Geoffrey Young [EMAIL PROTECTED] wrote: Tofu Optimist wrote: I would like to append a small line of log information to a file on certain apache2 requests. For this application, I am very concerned about speed, so i'm looking for fast simple solutions. if speed is the concern, just stick to apache's native logging mechanism. see recipe 16.5, Conditional Logging in the mod_perl developer's cookbook: http://www.modperlcookbook.org/chapters/ch16.pdf in mod_perl 2.0, it's still $r-subprocess_env(), but you need to load APR::Table first. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) --Geoff
Re: Sending a different protocol header
Hans wrote: I've done a fair amount of searching and still can not find an answer to this. I'm writing a mod_perl2 handler and would like to output my own headers. Specifically I'd like to output headers like this: - ICY 200 OK icy-notice1: some info icy-name: some info icy-url: some info Content-Length: length SOME CONTENT - When trying to output these headers it doesn't work and just becomes part of the content. If I remove the ICY 200 OK line, the rest of the headers work just fine. I'd like to override the HTTP/1.1 headers. How can this be done? try setting $r-assbackwards(1) before returning your response. this should supress the apache headers and allow only your own to get through, provided you print them instead of putting them in the headers_out table. btw, can you please explain what ICY is for me? the $r-assbackwards(1) thing was specifically implemented in mod_perl 1.0 to support ICY, and I used it in examples I give of this, but I always have to say that I have no idea what ICY is. thanks --Geoff
Re: Sending a different protocol header
assbackwards works. Thanks! When I first read your response about a method called assbackwards I thought it was sarcasm :) understandable :) actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. so, for HTTP/0.9 requests r-assbackwards is 1, otherwise it is 0. apache internally hacks r-assbackwards on various occasions where headers should be supressed in the response, such as with a subrequest. mod_perl also hacks the assbackwards flag to suit its needs. in mod_perl 1.0 $r-assbackwards did not exist (except in various XS extensions created solely for educational purposes :) but one of the cool things about mod_perl 2.0 is that the entire API is opened up (finally :) ICY is for IceCast, a protocol for sending meta information about music streams. cool, thanks. --Geoff
Re: Sending a different protocol header
Perrin Harkins wrote: On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote: actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. Clearly this works, but wouldn't it be better to implement a protocol handler for IceCast instead? Or is that just overkill for this? I dunno. that IceCast is a protocol seems to make it a perfect candidate for a protocol handler. however, since I have yet to play with that aspect of apache or mod_perl, I don't know the overhead involved, especially if an ICY request is the same as an HTTP request, and supressing headers is the only difference between HTTP and ICY responses. but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support the idea of protocol handlers, if you're interested. see http://perl.apache.org/docs/2.0/user/handlers/protocols.html --Geoff
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: Hello again.. On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote: see Apache::SSI for mp1 - it does exactly what you are trying to do and is subclassable, so you can add your own tags/functionality if you want. That is exactly what I am already doing. When using #exec directive I noticed I could not set the headers properly. typically, a subrequest gets its headers from the current request. if you want to alter them, use $r-headers_in-set, but this is generally only used to test what-if scenarios: what if the current request had a cookie, could it access this document? anyway, if you need that, then you could probably create your own subclass and override ssi_exec to simply set the incoming headers and then SUPER::ssi_exec. or something like that (off the top of my head, anyway ;) see recipe 5.7 in the mod_perl developer's cookbook for that, or look at the Apache::SSI source, which does it a different way. That is something i have yet to get my hands on! the book has a simpler example as well, but you should be able to figure out the important LWP bits from the online code example http://www.modperlcookbook.org/code/ch05/Cookbook/SubRequestContent.pm --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r-headers_out Location and Set-Cookie
Michael wrote:
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-headers_out-set(Location = $location);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
How would you have written it?
http://marc.theaimsgroup.com/?l=apache-modperlm=106260380606735w=2
thanks, I meant to put that in myself :)
Seems to me you'd want to *return* REDIRECT, not set $r-status to REDIRECT.
Here's what I do in this case:
$r-header_out(Location = $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
actually, the return value is entirely ignored in Registry scripts - that's
why we need the $r-status hack, which is not needed (or desired) in
handlers. if you returned SERVER_ERROR it would still work, so long as you
set $r-status :)
however, yes, I prefer your way and return REDIRECT instead of OK - it just
seems to make things that much closer to handler behavior, as well as being
a bit more intuitive.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: FW: $r-headers_out Location and Set-Cookie
Garrett Goebel wrote: [Note: reposting, the original post appears to have dropped through the cracks] not only did I get two of these already, but I also posted a reply :) --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Can't get a mod_perl.so...
I still don't have a mod_perl.so. There are no errors anywhere. I'm using mod_perl 1.28 source. I'm running Apache 1.3.26 on Linux 2.4.18 (Slackware 8). you only get a shared object file if you compile mod_perl as a DSO, which is not the default with mod_perl 1.28. to check whether mod_perl is installed, try running /usr/local/apache/bin/httpd -l and check for mod_perl.c at the bottom. if you want mod_perl as a dso use USE_DSO=1 besides the documentation on perl.apache.org you can find additional installation instructions at http://www.modperlcookbook.org/chapters/ch01.pdf HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Can't get a mod_perl.so...
perl Makefile.PL APACHE_SRC=../apache_1.3.26_modperl/ APACHE_PREFIX=/usr/local/apache EVERYTHING=1 USE_DSO=1 USE_APACI=1 APACI_ARGS='--enable-module=rewrite, --enable-module=info, --enable-module=expires, --disable-module=userdir' DO_HTTPD=1 when I use those options, I end up with /usr/local/apache/libexec/libperl.so but only after I install the package - it's not in my mod_perl source tree. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r-headers_out Location and Set-Cookie
Garrett Goebel wrote:
Geoffrey Young wrote:
That's when you use Apache::compat, doing the mp1 syntax.
In mp2-speak that would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT);
notice that you don't need to call $r-send_http_header, it
doesn't exist in mp2.
not to mention it's entirely unnecessary (and undesirable) to
send headers on error responses such as redirects.
Why?
Appendix A.7 from the Stas' Practical mod_perl book states:
You should use err_headers_out( ), not headers_out( ),
when you want to send cookies in a REDIRECT response or
in any other non-2XX response
that's correct, but setting the headers is entirely different than sending them.
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-headers_out-set(Location = $location);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
How would you have written it?
the example is wrong - it should not have send_http_header() in it.
if you execute that script over telnet, you'll see two sets of headers.
apache automatically sends headers on errors - that's how you are able to
get standard 500 pages, etc.
and you should never set $r-status from a handler - for
Registry scripts it's ok, since we use it as a hack to get
around some things, but handlers should never manipulate the
value of $r-status.
Why is that?
if r-status is not HTTP_OK (200) then apache thinks that an ErrorDocument
has _also_ thrown an error, and it thus ends what would otherwise be a
recursive cycle of errors. by messing with r-status, you mess up Apache's
internal bookkeeping wrt the error document cycle.
--Geoff
/me sliently points to recipe 3.13 in the cookbook, too :)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Custom Log files Under MP2
Tofu Optimist wrote: I would like to append a small line of log information to a file on certain apache2 requests. For this application, I am very concerned about speed, so i'm looking for fast simple solutions. if speed is the concern, just stick to apache's native logging mechanism. see recipe 16.5, Conditional Logging in the mod_perl developer's cookbook: http://www.modperlcookbook.org/chapters/ch16.pdf in mod_perl 2.0, it's still $r-subprocess_env(), but you need to load APR::Table first. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: Stephen [EMAIL PROTECTED] wrote: I'm no expert at debugging C, but I dont think that the above looks too healthy Well, I think I have it figured out, more or less. The root cause of it seemed to be a rather, um, interesting bit of code in HTML::Mason::ApacheHandler which makes use of string eval and sprintf to define the handler() subroutine. The intent was to create a handler() routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute of : method). However, for some reason or another, handler() was being called as a regular sub, with one parameter. mp1 supports both $$ and :method, so no need to do something special to make it work for both mp1 and mp2. Preloading the module and using the explicit Module-handler method syntax in httpd.conf seems to have fixed it. preloading is required in mp1. the - syntax is not. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: MP_AP_PREFIX = /home/craig/temp/mod_perl-1.99_09/ hi craig. before we continue, please try the latest cvs (without the patch I sent) and see if your stuff segfaults there. if not, at least we know we've isolated the segfault and just have bad logic to fix :) if you need help with cvs, see http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_the_mod_perl_Source --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: problems with Apache::Filter
Stas Bekman wrote: Josh Chamas wrote: Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, IMHO, Apache::Filter does doesn't need to be ported to mp2. You have a native API for filtering. Geoff has posted a an alpha-port of Apache::SSI to the list some time ago. yes. Apache::SSI seems to be getting a bit of attention lately, so I'll probably pick up working on that again now :) --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
however, removing that logic causes api/lookup_uri2.t to fail, but I suspect this is an issue with puts() rather than the subrequest mechanism - changing puts() to print() makes everything work just fine. does puts() write directly to the wire, bypassing filters? Sorry, but that's cheating ;) rputs() never flushes data, print() flushes if $| == 1; ah, ok, that's the difference. So there is no problem with the r-main logic in mpxs_ap_run_sub_req, it's there for exactly this reason. no, there is definitely something wrong. someplace :) if I'm in a filter and call sub-run (which is what mod_include essentially does), mod_perl is silently passing along the data I'm in the middle of filtering. so, if the filter sees datatagdata and wants to substitute something for tag via a subrequest, it won't work - mpxs_ap_run_sub_req is flushing tag along before the filter gets the chance to decide about the data. as I said, nowhere in any of the module shipped with core do I find logic like this - mod_include and mod_cgi both seem to call ap_run_sub_req without flushing the main data stream (though mod_include does split the stream and send the data _prior to the tag_ off). I don't see why mod_perl needs to behave differently in this respect, but if flushing is required for other reasons I can't see, making it a tacit part of $sub-run seems the wrong solution since it goes against the intent of output filters. and you forgot to add to the patch a new file #t/htdocs/filter/subrequest.txt core subrequest yes, sorry. or even better: out_str_subreq_default out_str_subreq_modperl since these correspond to the SetHandler settings. will do. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Stas Bekman wrote:
Craig Shelley wrote:
I'll take a look at it. But you didn't supply a complete bug report
as explained http://perl.apache.org/bugs/. Please do so.
I think I've got this figured out.
the problem is with the r-main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being
operated on is explicity flushed. this is bad within a (streaming) filter
where you are expected to call $f-print yourself, as the data is sent
without your permission (you may be operating on it or not want to send it
at all). it also seemed to cause infinite loop in my tests because the
filter was seeing the same data over and over again.
I can't really understand the reason behind the code anyway, since I can't
see anywhere in core where such logic is applied before ap_run_sub_request -
everyone seems to call without regard to where in the data stream they
happen to be, so I don't get why mod_perl should be any different. indeed
commenting it out fixes the problem for me.
however, removing that logic causes api/lookup_uri2.t to fail, but I suspect
this is an issue with puts() rather than the subrequest mechanism - changing
puts() to print() makes everything work just fine. does puts() write
directly to the wire, bypassing filters?
anyway, attached is a patch against current cvs - fixes and a few filtering
subrequest tests. note that the patch does not mention the removal of
xs/Apache/SubRequest/Apache__SubRequest.h, which is no longer needed, so I
guess you should remove that file by hand before compiling.
craig - note that this patch affects the autogenerated code, so in order to
get it to work you'll need to apply it, then run make realclean, perl
Makefile.PL, etc.
--Geoff
Index: t/response/TestAPI/lookup_uri2.pm
===
RCS file: /home/cvspublic/modperl-2.0/t/response/TestAPI/lookup_uri2.pm,v
retrieving revision 1.3
diff -u -r1.3 lookup_uri2.pm
--- t/response/TestAPI/lookup_uri2.pm 27 Apr 2003 04:19:18 - 1.3
+++ t/response/TestAPI/lookup_uri2.pm 26 Aug 2003 19:55:50 -
@@ -11,7 +11,7 @@
sub myplan {
my $r = shift;
-$r-puts(1..3\nok 1\n);
+$r-print(1..3\nok 1\n);
Apache::OK;
}
@@ -19,7 +19,7 @@
sub ok3 {
my $r = shift;
-$r-puts(ok 3\n);
+$r-print(ok 3\n);
Apache::OK;
}
@@ -35,7 +35,7 @@
subrequest($r, 'myplan');
-$r-puts(ok 2\n);
+$r-print(ok 2\n);
subrequest($r, 'ok3');
Index: xs/maps/apache_functions.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/apache_functions.map,v
retrieving revision 1.64
diff -u -r1.64 apache_functions.map
--- xs/maps/apache_functions.map12 Jun 2003 23:27:03 - 1.64
+++ xs/maps/apache_functions.map26 Aug 2003 19:55:51 -
@@ -95,7 +95,7 @@
PACKAGE=Apache::SubRequest ISA=Apache::RequestRec
ap_destroy_sub_req | | r | DESTROY
- ap_run_sub_req | mpxs_ | | run
+ ap_run_sub_req | | r | run
MODULE=Apache::RequestIO PACKAGE=Apache::RequestRec
ap_discard_request_body
Index: xs/tables/current/ModPerl/FunctionTable.pm
===
RCS file: /home/cvspublic/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.119
diff -u -r1.119 FunctionTable.pm
--- xs/tables/current/ModPerl/FunctionTable.pm 20 Aug 2003 23:20:14 - 1.119
+++ xs/tables/current/ModPerl/FunctionTable.pm 26 Aug 2003 19:55:56 -
@@ -6170,24 +6170,6 @@
]
},
{
-'return_type' = 'int',
-'name' = 'mpxs_ap_run_sub_req',
-'attr' = [
- 'static',
- '__inline__'
-],
-'args' = [
- {
-'type' = 'PerlInterpreter *',
-'name' = 'my_perl'
- },
- {
-'type' = 'request_rec *',
-'name' = 'r'
- }
-]
- },
- {
'return_type' = 'apr_size_t',
'name' = 'mpxs_ap_rvputs',
'attr' = [
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ t/filter/TestFilter/out_str_sub_core.pm 2003-08-26 15:51:40.0 -0400
@@ -0,0 +1,78 @@
+package TestFilter::out_str_sub_core;
+
+use strict;
+use warnings FATAL = 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+
+use Apache::RequestRec ();
+use Apache::RequestIO ();
+use Apache::SubRequest ();
+
+use Apache::Filter ();
+
+use Apache::Const -compile = qw(OK);
+
+# include the contents of a subrequest
+# in the filter, a la mod_include's
+# !--#include virtual=/subrequest --
+
+sub include {
+
+my $filter = shift;
+
+unless ($filter-ctx) {
+# don't forget to remove the C-L header
+$filter-r-headers_out-unset('Content-Length');
+
+$filter-ctx(1);
+}
+
+while ($filter-read(my $buffer, 1024)){
+
+if ($buffer eq tag\n) {
+my $sub = $filter-r-lookup_uri('/core_subrequest/subrequest.txt');
+my $rc = $sub-run;
+
Re: SubRequest in Filter MP2 [QUESTION]
my $rr = $f-r-lookup_uri(subrequest.txt); #$rr-run; For some reason, the server segfaults when the above code is run (with the $rr-run line present) does anything change if you use $rr = $f-$r-lookup_uri(subrequest.txt, $f-next); ? --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: unsetting PerlTransHandler
Frank Maas wrote: On Thu, Aug 14, 2003 at 11:07:13AM -0400, Geoffrey Young wrote: There is actually a Location/LocationMatch sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed. which is what you found in the code - note the completely thrown away part. in essence, this means that the results of the Location config merging are discarded prior to translation, after which Location merging is done again. Ehm... considering both solutions worked and the quoted paragraph, shouldn't we read it as 'the results of this sequence can be used during the translation phase, but are thrown away after the translation has completed'. This would mean that the results are not discarded prior to translation, but after translation and that would also explain why the two solutions work... well, they can only be used during translation if the URI is unaltered. for instance, given the example we've seen already PerlTransHandler MyPackage::transhandler Location ... PerlHandler MyPackage::handler /Location checking get_handlers() in transhandler() only works because the initial merge (which is thrown away) ends up being the same merge as after translation. if any (other) trans handlers meddle with $r-uri (which is perfectly valid) then the initial get_handlers() call will report settings completely different than the end Location that is finally applied to the URL. so, I guess Location-specific settings can be used during translation, much in the same way that you can break encapsulation in Perl by simply accessing the object via its underlying hash - the feature works currently due to the way things are implemented, but using it is not guaranteed to work in the future (apache 2.0?), and may have unintended consequences in the present. in other words, it's a bad idea and people who know better certainly don't rely on it. --Geoff
Re: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
$r-content_type is generally set by mod_mime, during the mime-type phase,
according to it's rules. for most setups, it should be set to something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
Re: help on setting up a PerlFixupHandler
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase you need
to do two things - tell apache that mod_perl is in charge, and tell mod_perl
which Perl handler it should use. you've done the latter. for the former,
use $r-handler('perl-script'), which is analogous to SetHandler perl-script
that you would ordinarily see for a mod_perl setup.
HTH
--Geoff
Re: unsetting PerlTransHandler
Yes, I've implemented it also that way. But I thought Location acts on the
URI and in principle there can be a Location-specific transhandler. I'm
wondering why it is impossible?
trans handlers are used to map the URI to a filename, the result of which
lets Apache know to which Directory the URI belongs to. it can also
affect which Location the URI belongs to if that Location is paired with
an Alias directive. trying to make a trans handler Location specific
doesn't really make sense - if you are already in a Location section then
you should already know which file (or lack thereof) you want to serve.
that's just how Apache works.
For now I have implemented that particular case by
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
package MyPackage;
sub transhandler {
...
return DECLINED
if(grep {$_ eq __PACKAGE__.'::handler'} @{$r-get_handlers('PerlHandler')});
...
}
i.e. if my handler is installed return DECLINED.
I don't think that will work the way you desire - the PerlHandler directive
should not be merged into the current configuration for the request until
after the trans handler runs, so I wouldn't expect it to be present in
get_handlers() yet.
a better way is probably to let your PerlTransHandler run always. then, for
requests to Location use a PerlHeaderParserHandler to unset $r-filename.
HTH
--Geoff
Re: Apache::Reload and INC path partialy working
Bruce Tennant wrote: I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time. Here's my settings Apache/2.0.40 mod_perl-1.99_7 please upgrade to the latest CVS version and try again - 1.99_07 is very old. Linux 2.4.20-8 (RedHat9 I think) Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff Here's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when they do change, it dies when it tries to reload them and says they aren't in the @INC path. ok. can you show us @INC before and after the reload attempt? I'm curious as to whether PERL5LIB is being properly added to @INC for the request time interpreters. also, does it fail if you reload modules that are not in @INC? for instance, try touching CGI.pm or something in your site_lib and watch the debug messages. So it's like it is half working. Has anyone ! else seen this problem and have a possible fix? we'll find a fix if we can isolate and reproduce the problem, don't worry :) --Geoff
Re: Apache::Reload and INC path partialy working
Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff on second thought, try PerlSwitches -I/home/bruce/public_html/ffball/myff or PerlSwitches -Mlib=/home/bruce/public_html/ffball/myff instead of PERL5LIB --Geoff
Re: unsetting PerlTransHandler
I understand translation handlers cannot be Directory-specific. But Location directives apply before any translation handler is called (see below). yes they do, but not really. to really understand this, see http://httpd.apache.org/docs/sections.html specifically, There is actually a Location/LocationMatch sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed. which is what you found in the code - note the completely thrown away part. in essence, this means that the results of the Location config merging are discarded prior to translation, after which Location merging is done again. regardless, officially apache translation (which includes the PerlTransHandler) cannot be Location specific - directives must appear outside of Directory, Location, and Files (and their regex counterparts). if you look at other modules that implement translation handlers (mod_rewrite, for instance), you'll see that their translation directives all have RSRC_CONF prototypes, which prohibits their placement inside of these containers. --Geoff
Re: request for help with reproducing problem
But you really want to learn how to write tests with Apache::Test if you do any serious mod_perl development, so there is no excuse not to learn Apache::Test, not talking about the fact that there are hundreds of existing tests as examples, the tutorial http://perl.apache.org/docs/general/testing/testing.html and the slowly growing manpages. not to mention http://www.perl.com/pub/a/2003/05/22/testing.html from which I quote: Secretly, I'm hoping that Apache-Test becomes so popular that end-users start wrapping their bug reports up in little, self-contained, Apache-Test-based tarballs so anyone can reproduce the problem. --Geoff
Re: Mod_perl how to include the result of mod_autoindex?
Thomas Klausner wrote: Hi! On Mon, Aug 11, 2003 at 04:37:45 -0500, Slava Bizyayev wrote: It's not quite the truth... You can do all that staff on Apache 1.3 with appropriate skills. See LWP for example. If you mean to grab the output of e.g. mod_autoindex by issueing a sperate request using LWP, that's definitly possible. But I would classify this as a hack and not as a proper way to implement a feature. and it's perl - as you had said, if you stay within perl's boundaries, much more is possible :) Or /is/ there a clean way to properly filter output from different response handlers with Apache 1.3? I'd realy like to hear about it... mod_gzip apparently does this, though I've never evaluated the code or how they do it. http://www.schroepl.net/projekte/mod_gzip/ which is why I generally say filtering content is impossible in 1.3 (well, really, really hard) --Geoff
Re: $r-headers_out Location and Set-Cookie
That's when you use Apache::compat, doing the mp1 syntax. In mp2-speak
that would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT);
notice that you don't need to call $r-send_http_header, it doesn't
exist in mp2.
not to mention it's entirely unnecessary (and undesirable) to send headers
on error responses such as redirects.
and you should never set $r-status from a handler - for Registry scripts
it's ok, since we use it as a hack to get around some things, but handlers
should never manipulate the value of $r-status.
--Geoff
Re: help on setting up a PerlFixupHandler
So, while I'm not 100% sure about this, logically the $r-content_type
should be empty before the response is prepared to be sent to the browser,
so it should be empty in the Fixup stage.
not necessarily.
if you request index.html, mod_mime (at the mime-type phase) will set the
content type to text/html based on the file extension. mod_mime_magic will
do the same, but by analyzing the contents of the file.
if you are generating dynamic content and there is no file type to examine
(or consistently relate, as .cgi can produce multiple CTs), no default type,
and no file to examine, then there is no way the mime modules can set a
content type. the end result would be undef in fixup and beyond.
In fact what I miss (and I guess I'm not alone ;-) is a documentation that
would take the $r from the newly born state and describe what's
added/deleted to it during a full process loop, at each stage.
there is lots of documentation on this kind of thing, but nothing specific
like $r-content_type is set during the mime-type phase because things
like this are dependent on varying circumstances.
Part III of the mod_perl Developer's Cookbook talks about the each phase of
the request cycle in depth. you can read part of it from
http://www.modperlcookbook.org/. the eagle book also covers it.
Besides I'd like to know about each major optional module (like mod_rewrite,
mod_ssl, etc) where they intervine in the loop and what they read/or set.
Most of these one can guess but I'm not aware of such a documentation.
that's complex. for instance, mod_rewrite can enter just about every part
of the request cycle, depending on how it's configured.
the way to discover this is to look at the code (remember, it's open :) - at
the end of each extension module is the place where hooks are typically
registered. look for a line such as
module MODULE_VAR_EXPORT rewrite_module = {
which begins the list of phases the module hooks into.
HTH
--Geoff
Re: the installation nightmare continues
So I built, tested and made apache with: $ ./configure --prefix=/usr/local/apache $ make $ make install $ usr/locall/apache/bin/apachectl start (started fine) try letting mod_perl do the heavy lifting - mod_perl will build both itself and apache if you let it. after unzipping both apache and mod_perl sources to the same local root (say, ~jeff/src) just cd to the mod_perl directory and... edit makepl_args.mod_perl: APACHE_SRC=../apache-1.3/src APACHE_PREFIX=/usr/local/apache DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=so (add whatever modules you want here) then (as non-root user) $ perl Makefile.PL $ make $ make test and you should be good to go. in addition to the perl.apache.org install doc, this might help: http://www.modperlcookbook.org/chapters/ch01.pdf HTH --Geoff
Re: handlers versus scripts, SSI difference
But it seems to be that with modperl as DSO this directive does not work, and that Apache::include is only a modperl1.x funcionality, so discarted in mod perl 2. I've started this port, but it's a long way from being completed - it doesn't work right and dumps core, but I haven't looked at it in quite a while. oh, and it's really ugly too. in other words, very much a work in progress. here it is if you want to help - I'll probably get back to it in a few weeks. http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-SSI-2.0.tar.gz --Geoff
Re: rflush() not working as documented?
Martin Wickman wrote: Just checking that this did not get lost on the way. Anyone care to give me a hint? On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote: Hello According to docs[1], $r-rflush() should create a new brigade with data. It does not. I've seen this also, but was never able to isolate a cause. It seems the docs and/or my understanding of this is in error. This is with: Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0 And I am using the streaming filter api. [1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers Long version below: -- I have tried to make my outputfilter clever enough so it can handle being called several times, with tags potentially split between several brigades. see the code and tests from http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz which should give you more ideas about how to code this (and how I tested long input values) the corresponding articles might help: http://www.perl.com/pub/a/2003/04/17/filters.html http://www.perl.com/pub/a/2003/05/22/testing.html I've been meaning to chat with stas about the rflush for a while now. perhaps we can prioritize it :) --Geoff
Re: PerlTransHandler headaches
Glenn E. Bailey III wrote:
Hello,
While I am not new to Perl, I am completely new to mod_perl.
check out the resources at http://perl.apache.org/ - there's lots of good
information there :)
sub handler {
my $r = shift;
return OK;
}
1;
And not matter what I always get a 404 with the following in the log:
[Tue Jul 29 03:27:27 2003] [error] [client 10.0.0.1] File does not
exist: /
the translation phase is there to map the URI to a filename. by returning
OK, you're telling Apache that you've done the translation (that is, you
have set $r-filename to something useful). since you didn't set
$r-filename, apache is returning 404, since it can't serve the value of
$r-filename.
so, the general rule for PerlTransHandlers is to return DECLINED unless you
set $r-filename.
chapter 12 in the mod_perl Developer's Cookbook deals specifically with the
PerlTransHandler and is as good a place to start learning as any.
HTH
--Geoff
Re: PerlTransHandler headaches
: so, the general rule for PerlTransHandlers is to return
: DECLINED unless you
: set $r-filename.
What I am trying to do is just test, to make sure it is working
ok. So what I did is wrote the following snippit:
sub handler {
my $r = shift;
return DECLINED;
}
That should still allow me to pull up my default content, correct? As
of now it still gives me a 404 ..
make sure the request works without the PerlTransHandler installed first.
if it does, then adding that routine should be ok.
don't forget, you can't just change handlers and expect them to work -
because the code is loaded the first time it's seen and not on every
request, you either need to install Apache::StatINC, Apache::Reload, set
PerlFreshRestart On and restart the server or (simplest) fully shutdown and
startup the server.
--Geoff
Re: Life of env vars set using Apache.pm-subprocess_env
Hari Bhaskaran wrote: Hi, Does apache clear env variables set by $r-subprocess_env() at the end of the request? sort of... Put in another way - Does apache start with a 'clean' environment for every request? that's a more accurate description :) --Geoff
Re: Combining authen-handler with mod_auth
Instead of trying to cram multiple perl-script into the same Authen phase, which btw could not be done without patching Apache and/or mod_perl, if by perl-script you mean mod_perl handlers, that's not really true. currently, mod_perl will run all configured PerlAuthenHandlers until one returns an Apache error (401, 500, etc). when I get back from vacation in a few weeks, the first item on my list is changing this so that mod_perl behaves exactly like Apache: namely, that the first OK passes control to the next phase and terminates the current phase. see http://marc.theaimsgroup.com/?l=apache-modperl-devm=105431735200617w=2 [stuff snipped] By keeping count like this (and assuming it works in a real situation), one can device lots of cool ways to add login and password policies. Just change relevant part in the Bouncer/Ledger. (Btw, I am using Cache::FileCache to keep track of number of failed retries.) I'll take a closer look at this in a few weeks when I'm back full time, but right now I think I would have coded it all in the PerlAuthenHandler - I think that basic housekeeping like last-auth, etc all are ok things to put into that phase, so it makes a certain amount of sense to add your denial rules to that phase as well. anyway, I'm essentially offline for the next two weeks, but if you ping me after that we can talk more. good luck --Geoff
Apache 2.1 Authentication Providers in Perl
hi all... buried within perl.com this week is my latest article http://www.perl.com/pub/a/2003/07/08/mod_perl.html which covers how to use Apache 2.1 authentication from Perl. one of the biggest benefits of Apache 2.1 auth over Apache 2.0 (or even 1.3) is the ease at which it opens up Digest auth, so if that is of interest to you then you really should check out the 2.1 Apache branch. the Apache::AuthenHook module the article discusses is on CPAN http://search.cpan.org/author/GEOFF/Apache-AuthenHook-2.00_01/ enjoy. --Geoff
Re: Combining authen-handler with mod_auth
Thanks! I guess that may be possible, but somewhat problematic since I like to stay with the distros apache-version. Btw, I remember seeing something about APR_HOOK_(LAST|FIRST|...) in the docs on perl.apache.org. Not implemented yet? I'm not sure what docs you're thinking about, but that change should be ok. I know that I'm using those constants in some XS and all is ok. I think a lot of interesting password policies could be implemented if it was possible to run perl-code before and after existing authentication modules. Is it feasible to add this to the current mod_perl as a runtime option? runtime is not likely to be possible. I'm considering a patch that would make the hook behavior configurable as a compile-time option, however - modperl_hooks.c is autogenerated during the config process, so it should be trivial to change the hook order without folks like you needing to patch the code yourself. --Geoff
Re: Combining authen-handler with mod_auth
Martin Wickman wrote: Hello The short version: How can I force my mod_perl Authen-handler to run after mod_auth and not before it? in Apache 1.3 you could control this with CleanModuleList/AddModule, but those directives don't exist in 2.0. I think the only way to do it in 2.0 is to change modperl_hooks.c and recompile. try changing this ap_hook_authen(modperl_authen_handler, NULL, NULL, APR_HOOK_FIRST); to this ap_hook_authen(modperl_authen_handler, NULL, NULL, APR_HOOK_LAST); HTH --Geoff
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)
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: Best compression for mod_perl application?
The other odd problem I got was that if anywhere in my perl code I printed nothing (e.g. print or $foo=;print $foo), I'd get this error: error: 20014:Error string not specified yet at /my/perl/code.pl line 123 This error was both blurted to the error_log and to the web page (screwing up the page and truncating further output). I changed my code to print instead of (HTML ignores extra white-space, so no biggie), and the errors all went away. So, I see this as an annoyance more than a serious bug. if you're using mod_perl for your perl script, it might be a mod_perl issue an not mod_deflate - try the same from a mod_cgi script and see if it has the same problem. if not, we probably need to dig around mod_perl core for a fix. --Geoff
Re: mod_perl And Redirection
$r-headers_in-unset(Content-length); $r-header_out(Location = $uri); $r-status(REDIRECT); $r-send_http_header; return REDIRECT; well, you shouldn't ever mess with $r-status - that messes up Apache's internal bookkeeping. and don't send headers on an error response, which is what REDIRECT is as far as Apache is concerned. so, you end up with $r-header_out(Location = $uri); return REDIRECT; HTH --Geoff
Re: dynamic Authentication with PerlHeaderParserHandler?
Meik Hellmund wrote: I tried to modify the Web agenda/calendar chronos (http://chronoss.sourceforge.net) in such a way that everyone can look at the calendar without authentication but changes need basic authentication. In other words, URLs like http://.../chronos?action=showday; should go through without authentication and only if an URL like http://.../chronos?action=editevent; is requested, basic authentication takes place. probably what you want is something similar to Recipe 13.5 in the Cookbook, Conditional Authentication. you can find all of chapter 13 online for free http://www.modperlcookbook.org/chapters.html HTH --Geoff
Re: mod_perl PerlTransHandler weirdness
Joel Bernstein wrote: Hi, I would not be surprised if this problem has arisen due to me expecting more from Apache+mod_perl than it's capable of. The server is running Apache 1.3.mumble with mod_perl and mod_php. The site has been entirely built in PHP, by somebody else. They want the facility for http://foo.bar.com/david to redirect to http://foo.bar.com/?page=publicprofile.phpname=david . the secret to the PerlTransHandler is this: it is there to make the URI into a file. so, if you deconstruct the URI to a point where you know which real file you want to serve (at a filesystem level, that is, like /usr/local/apache/htdocs/foo.html) then set $r-filename and return OK. otherwise, what you want to do is set $r-uri to the relative URI you want Apache to deconstruct and return DECLINED. the default Apache trans handler will then map it to a filename for you. Apache will also take care of directories, non-files (like URIs such as /server-status which do not map to files) and so on. so, given http://foo.bar.com/?page=publicprofile.phpname=david you might want to really execute http://foo.bar.com/publicprofile.php?name=david, right? so, parse the incoming $uri and set $r-uri to '/publicprofile.php?name=david' and return DECLINED. now, if publicprofile.php is not running as PHP it means that mod_php is not set up properly - perhaps you not used AddHandler to specify .php files as mod_php scripts, or perhaps have used SetHandler to override the default handler for the Location that governs. the way to test this is to request the resulting uri (/publicprofile.php?name=david) and see if it works without your trans handler. once that works, just insert the trans handler and try again. It was suggested that path_info may not be available yet by the trans phase. yup. $r-path_info is what is left over from the URI once the URI is mapped to a file or Location, so it should be empty until after translation (and possibly empty after as well). HTH --Geoff
Re: Can't call method is_initial_req without a package or objectreference at .........
Martin Moss wrote:
All,
I'm having some problems with Apache giving me grief, or most probably me
getting my knickers in a complete twist.
I get the following error:-
Can't call method is_initial_req without a package or object reference at
.
It seems to happen when my URL ends like this:-
/somepath/16
but not when it ends like this:-
/somepath/16/
/somepath/16 is resollved by mod_dir to /somepath/16/ using an internal redirect, and...
unless ($r-is_main )
{
print STDERR Apache::Request is not Main, Getting Main\n;
print STDERR Dumper($r);
$r=$r-main;
print STDERR Main Apache::Request is:-\n;
print STDERR Dumper($r);
print STDERR DECLINING\n;
return DECLINED;
}
you're not returning an object from your constructor on internal redirects :)
HTH
--Geoff
Re: getting *any* variables out of the server environment
Ryan Muldoon wrote:
Geoffrey,
Thanks for the explanation. Unfortunately, I think I am still a little
unclear as to how to proceed. If I understand you correctly, my first
method is completely wrongheaded.
:)
(I tried this because it is how the
Writing Apache Modules with Perl and C does it. p.327)
don't have my book handy to check that.
So it sounds
like the second way is the appropriate usage for subprocess_env(). But
it seems like you're saying that I shouldn't be using that at all.
no, I wasn't saying that :) subprocess_env() from the main request is the
right way to go. I was just trying to let you know that it has nothing to
do with %ENV really.
Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature.
ok, those are definitely setup in the subprocess_env table according to the
code I just took a look at. however...
According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate.
from what I can see, that's not entirely true. they are set in
subprocess_env where they sit and wait, presumably for somebody else to call
add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
the problem you're seeing is that these variables are setup during the fixup
phase, so in using a PerlAuthenHandler you're trying to see them too early.
int ssl_hook_Fixup(request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r-server);
SSLDirConfigRec *dc = myDirConfig(r);
table *e = r-subprocess_env;
...
/*
* Annotate the SSI/CGI environment with standard SSL information
*/
/* the always present HTTPS (=HTTP over SSL) flag! */
ap_table_set(e, HTTPS, on);
/* standard SSL environment variables */
if (dc-nOptions SSL_OPT_STDENVVARS) {
for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
var = (char *)ssl_hook_Fixup_vars[i];
val = ssl_var_lookup(r-pool, r-server, r-connection, r, var);
if (!strIsEmpty(val))
ap_table_set(e, var, val);
}
}
in other words, you're SOL from the current request. perhaps this is why
the eagle book said to get them from a subrequest - presumably the
subrequest would have them, since it runs through the fixup phase and SSL
stuff is per-connection and not per-request.
Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.
Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
don't do that. PerlPassEnv is for passing variables such as those from
/etc/profile to the %ENV of the Apache child processes.
--Geoff
Re: getting *any* variables out of the server environment
Ok, removed. Thank you very much for the in-depth replies. It is very useful. Unfortunately any variable-reading continues to elude me. But I really appreciate all the help! well, it sounds like you are having a larger problem that just mod_ssl-based variables. since you mention you're interested in learning... :) if you really want to track this down you could start from the beginning, meaning a bare bones server and a bare bones mod_perl content handler that merely iterates over %ENV and $r-subprocess_env() (see the do() method from Apache::Table) this kind of bare bones thing used to be a pain, but with Apache-Test, it has gotten _lots_ easier. you can find Apache-Test on CPAN http://search.cpan.org/CPAN/authors/id/S/ST/STAS/Apache-Test-1.01.tar.gz you can look at some of the SSL tests in the Perl-Framework http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/ to see how they use Apache-Test to test SSL based things. for instance env.t tests basic environment setting for SSL connections - you can use that as the starting point for writing tests for your own stuff. or you can even download the Perl framework from http://httpd.apache.org/test/ and run the ssl tests to make sure you're server is configured properly. just some advice, and you certainly don't need to go through all the effort of reading, setting up the test environment, etc. however, once you get Apache-Test set up it will make your module development much, much easier, and you'll be able to pinpoint exactly where things go wrong much easier. some basic explanations and pointers to other docs can be found here http://www.perl.com/pub/a/2003/05/22/testing.html HTH --Geoff
[ANNOUNCE] Practical mod_perl is out!
well, the (long) wait is now over - Practical mod_perl is here. weighing in at a whopping 924 pages, Practical mod_perl really needs no introduction for those that are already familiar with the mod_perl Guide. however, from the ORA catalog description: From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl. O'Reilly has a sample chapter online http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf the book's official website is http://www.modperlbook.org/ where you will find links to ways to purchse the book. kudos Stas and Eric! --Geoff
Re: [ANNOUNCE] Practical mod_perl is out!
Frank Maas wrote: well, the (long) wait is now over - Practical mod_perl is here. Geoff, you might be the best person to ask and it might be a worthwhile extension to the mod_perl-documentation: why would one use this new book if (s)he has the mod_perl cookbook already. that's a valid question. the way I look at things is like this. mod_perl is in a very unique position. of the three substantial books available on mod_perl, all are useful and authoritative, and all overlap very, very little. for the most part, I would say that the eagle book is best viewed as the main API reference for mod_perl - (almost) all the API functions are explained and illustrated there. it's also a good introductory text on basic Apache functionality and how mod_perl ties into Apache. I think everyone would agree that to do mod_perl you need to own the eagle book. the cookbook tries to show what having the C Apache API at your fingertips really means to Perl programmers. for the most part, it gives lots of examples of using (and abusing) the mod_perl API as a means to extending (and contorting) Apache. there is very little there, for instance, on running and configuring a server, but lots there on programming the deepest recesses of the server. practical mod_perl I think is more of an overall guide to deploying mod_perl services - everything from basic setup and coding to advanced configurations and performance techniques. essentially an overhauled, reworked, and polished Guide, this book has been in the works for a long time, and it contains very valuable information you won't find anywhere else. as I said, you'll find very little overlap between the different books. I know I tried very hard not to duplicate information that you could simply find in the eagle book, and I had advance knowledge of what was in the new book, so I tried not to duplicate information available there either. Stas and Eric I'm sure did the same. I am not trying to set a new war between authors here actually, we're all very much on friendly terms, so a war isn't likely. despite writing through different publishers, we all have the same idea - namely, to promote mod_perl and help document it as best we can. I know that's not something you find in open source every day, but you'll find us all drinking together at OSCon again this year :) --Geoff
Re: Stacked Handlers Location directive -- inside and outside virtualhost
When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is invoked. MyModule code checks for IP after reading a file from xyz directory. If the host ip matches with the one in the file, it returns OK and the PerlAuthzHandler never gets called and the webpage is served to the user. you may want to try using a PerlAccessHander for checking the IP, then combine that with Satisfy Any (as opposed to the Satisfy All default). HTH --Geoff
perl.com: Testing mod_perl 2.0
for those who haven't already seen it, perl.com ran the second of my series of articles on mod_perl 2.0 late last week. the title is actually a bit decieving. it's about using the Apache-Test testing framework, but although Apache-Test is shown in a mod_perl 2.0 context, Apache-Test can be used with mod_perl 1.0 as well - many of the illustrations are cross platform. the code from the article can be downloaded from http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz or, for the mod_perl 1.0 version, http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-1.0.tar.gz if you're interested in trying it out. enjoy --Geoff In our continuing mod_perl 2.0 series, Geoff Young looks at the new testing scheme, Apache-Test, and how it fits in with your mod_perl programs. http://www.perl.com/pub/a/2003/05/22/testing.html
Re: [mp2] httpd.conf Perl block problems
The first bug is a known one: apparently, recent mod_perls are sensitive to the syntax of the Perl tag: they require a space in it, like this: Perl I hope this is just a bug that hasn't risen to the top of the priority list yet, and that the mod_perl folk don't intend to keep this sytax. this is due to a limitation of apache 2.0. there _may_ be a way around it, but probably not any time soon. Once that was fixed, I found a new problem. I recieved errors like this: Syntax error on line 1059 of /etc/httpd/conf/httpd.conf: Bareword Apache::OK not allowed while strict subs in use at /usr/lib/perl5/site_perl/5.8.0//i386-linux-thread-multi/Apache/PerlSection.pm line 47.!BEGIN not safe after errors--compilation aborted at /usr/lib/perl5/site_perl/5.8.0//i386-linux-thread-multi/Apache/PerlSection.pm line 58.!Compilation failed in require at (eval 57) line 3.! try this patch, which was introduced after 1.99_09 Index: lib/Apache/PerlSection.pm === RCS file: /home/cvspublic/modperl-2.0/lib/Apache/PerlSection.pm,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- lib/Apache/PerlSection.pm 7 Oct 2002 15:45:52 - 1.3 +++ lib/Apache/PerlSection.pm 20 May 2003 01:20:09 - 1.4 @@ -7,6 +7,10 @@ use Apache::CmdParms (); use Apache::Directive (); +use APR::Table (); +use Apache::Server (); +use Apache::ServerUtil (); +use Apache::Const -compile = qw(OK); use constant SPECIAL_NAME = 'PerlConfig'; --Geoff
Re: [mp1] .htaccess and mod_perl
Michael L. Artz wrote:
I am stuck in an Ensim environment
ugh.
What is possible within an .htaccess file as far as perl configuration
for mod_perl 1?
just about anything. I use an Ensim installation, and am constantly
frustrated by it. however, there are ways around just about anything. for
instance, I couldn't install an ErrorDocument in a .htaccess file for some
reason. fine, I just used
PerlInitHandler 'sub { shift-custom_response(404, /notfound.html); return 0}'
and problem solved :) you can use this approach for just about anything -
I've also use $r-handler('default-handler') to force .cgi documents to be
un-executed and shown as plain text (useful for code examples :). and it
doesn't need to be from an anonymous sub either.
What happens with
PerlModule directives, i.e. does the module get loaded only once, the
first time that apache processes the .htaccess, or every time apache
hits the directory?
it probably won't matter - like use(), perl will only use() the module once.
Similarly, If I am developing a module in place and
PerlModule it within an .htaccess, will it be reloaded whenever apache
hits the directory, or only once?
modules are only loaded once - the first time they are use()d per-child (or
at server init)
If its only once, can I force a
reload of the module?
use
PerlInitHandler Apache::StatINC
to reload them during development (I've also used this on ensim :)
HTH
--Geoff
Re: [mp1] .htaccess and mod_perl
Apache::StatINC is R.I.P. Use Apache::Reload instead. but Apache::StatINC comes with mp1 and Apache::Reload doesn't - it's difficult to install modules on these ensim boxes since you don't have root (and yes, there are other ways around it of course :) --Geoff
Re: [mp2] httpd.conf Perl block problems
+use Apache::Const -compile = qw(OK); Without trying it, I'm sure that line will fix the error I'm seeing. I'd try it, but my RH9 box can't be disturbed at the moment. you will find that you need all the lines in that patch to get it to work - the error you are seeing is just masking others that will occur at runtime :) --Geoff
Re: checking what values have been set using pnotes/notes
Martin Moss wrote: All, Is there a way to work out what values have been set using pnotes/notes, So that a cleanup Handler can dynamically clear the values, rather than only clear ones pre-programmed? both notes and pnotes are guaranteed fresh at the start of each request, so there is no need for you to clean them up yourself. --Geoff
Re: AuthDBI logoff
Todd White wrote:
if there was a means by which i could strip out the Authorization header
in the client request, this would force a 401 response from the server
which would also satisfy my specific need.
is there a means by which i can manipulate an incoming request header from
the client?
Location /foo
PerlInitHandler 'sub { shift-headers_out-unset(Authorization); 0 }'
/Location
or something similar - you get the idea :)
--Geoff
Re: gaining access to config directives of other modules
dorian wrote: i know Apache::Module can get at all the installed modules and their directives, and even the spec of those directives, but what about the actual values of those directives? i notice Apache::Module is old, but i don't see anything else out there that looks like it will come close to doing the job. insight is welcome. Apache::Module is really cool, old or not, but probably isn't really production material based on the underlying wizardry. this thread offers a few different solutions, in increasing level of segfault probability :) http://marc.theaimsgroup.com/?l=apache-modperlm=103791699126881w=2 HTH --Geoff
Re: mod_perl.pm and Apache 2
Chris Majewski wrote: OK, I've resolved the mod_perl.pm dependency by reinstalling mod_perl-1.99_08 (from src). But now I get this when trying to install Apache::Cookie Can't locate Apache/MyConfig.pm in @INC (@INC contains: /usr/perl5/5.6.1/lib/sun4-solaris-64int /usr/perl5/5.6.1/lib /usr/perl5/site_perl/5.6.1/sun4-solaris-64int /usr/perl5/site_perl/5.6.1 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int /usr/perl5/vendor_perl/5.6.1 /usr/perl5/vendor_perl .) at Makefile.PL line 54. BEGIN failed--compilation aborted at Makefile.PL line 54. Apache::Cookie has not (yet) been ported over to mod_perl 2.0. what you want is: Apache 1.3.27 (http://www.apache.org/dist/httpd/apache_1.3.27.tar.gz) mod_perl 1.27 (http://perl.apache.org/dist/mod_perl-1.27.tar.gz) good luck. --Geoff
Re: Content-Type not working on MSIE
Andrew Ho wrote: Hello, SBCan someone please summarize the problem and add possible solutions and SBpost it here so we can add it to this document: SBhttp://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html Sometimes, MSIE will ignore the MIME type specified in a Content-Type header nice recap andrew :) we mention the problem briefly, as well as the three solutions you offer, in the cookbook, Recipe 5.6. Using the URI to Force a MIME Type maybe a pointer there is a good thing to have too :) --Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote: Thanks, that worked. Now I can use the regular authentication stuff. As I said in my last email, in the interest of preventing location pollution, is there some way I could make those PerlSetVars available to subsequent requests to a different location? I can't think of any way to do it without copying them to a separate location for each one. Perhaps with some kind of shared memory? well, given your example setup Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user ErrorDocument 401 /auth_fail_bob /Location /Location /auth_fail_bob SetHandler perl-script PerlHandler AuthFailure PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 /Location I would think you could make that ErrorDocument 401 /auth_fail Location /bob AuthType basic AuthName bob PerlAuthenHandler Module::authen PerlAuthzHandler Module::authz PerlSetVar system_id 123 PerlSetVar enc_key 187187815781 Require valid-user /Location /Location /auth_fail SetHandler perl-script PerlHandler AuthFailure /Location the use the $r-prev() trick - requests to /bob that result in 401 errors handled by /auth_fail will have bob's PerlSetVar stuff in $r-prev-dir_config, same for /bill and /biff. is that not what you mean? --Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote: Partially, and yes that seems to work. But here's the thing: When a user fails to enter a good password they will be given a chance to enter questions like What is your mother's maiden name, etc. and get their account unlocked. Without passing the enc_key and system_id in form parameters, is there any way I could make them available to whichever handler that is for the full series of requests? The handler gets those values when the user first gets to auth_fail but after that there isn't really any way I can keep passing them on, is there? nope, except by virtue of redirecting them back to /bob and starting the cycle over again. --Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote: I have a mod_perl handler set as the 401 ErrorDocument for a certain location that requires authentication. I would like to store data in notes() in the first location so that the 401 handler can access them. Is that possible? So far I haven't been able to get it to work. try $r-prev-notes If it is not, is there some way I could internally mimic Apache's authentication challenge/response setup? For instance, what happens when you return AUTH_REQUIRED to Apache? this is all explained in chapter 13 in the cookbook, as well as in the eagle book. for an example of plugging into authentication, see http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm Is it possible to do this inside a mod_perl handler by using set_handlers()? well, not really. unfortunately, you can't just set or push authentication, since Apache skips it unless you have a Require directive attached to the ErrorDocument. HTH --Geoff
Re: notes() and mod_perl ErrorDocuments
Hann, Brian wrote:
Actually I think I got it, but thanks for the tip on $r-prev-notes.
I'll have to give it a try. And yes, I've been poring over the cookbook
for most of the day :)
:)
Here's what I ended up doing: When I hit a place in my authen module
that required me to do:
$r-note_basic_failure;
return AUTH_REQUIRED;
I would instead do:
$r-handler('perl-script');
$r-set_handlers('PerlHandler' = ['AuthFailure']);
return OK;
this seems really strange. I think I'd rather see a call to
custom_response() to set up the error processing rather than
short-circuiting the API.
Then in AuthFailure I have this:
$r-note_basic_auth_failure;
$r-content_type('text/html; charset=ISO-8859-1');
$r-status(401);
you shouldn't ever set the status of the the request - it mucks up Apache's
internal ErrorDocument cycle. I wouldn't be surprised if the results of all
this, in a test via telnet, didn't show something suspicious (like
Additionally, the server encountered a 401... or something).
$r-send_http_header;
So far it seems to be working fine, and my notes() are coming across.
well, if it works, then... :)
but reconsider the design a bit - I'm sure you can do what you want using
the typical API formula. after all, using the authentication phase for
authentication is why the phase is there: there should be no need to set up
WWW-Authenticate headers from the content phase.
HTH
--Geoff
Re: [mp2] adding SERVER_ROOT and SERVER_ROOT/lib/perl to @INC
Stas Bekman wrote: Perrin Harkins wrote: Stas Bekman wrote: The question is, do we want to have this feature in mp2? I thought it was cool to have it automatically add a path relative to the server root, because it makes it feel more like you are writing real Apache modules, and not just CGI scripts. It's just a warm fuzzy thing really. I have no problem with dropping that feature and adding the path myself in startup.pl or httpd.conf. I'm +0 on adding this feature. While I have never used it myself, I see no harm in keeping back-compatibility with 1.0. Unless someone has a reason for not having it I'll commit the patch I've posted earlier. in 1.0 I used it all the time and liked having it there. however, I suspect that doug left it out on purpose - IIRC PerlSwitches was his answer when this was asked before (maybe it was at a conference, I can't remember). anyway, I'd say do it and let purists complain later - it will make porting that much more seamless. --Geoff
Re: Tracing double accesshandler invocation
Nick Tonkin wrote:
Hi Ric,
This has been a nightmare trying to debug, but I think I've found where
the cause is in my module.
In my Access handler I have some code designed to skip Access handling for
images (let the html pages take care of that). The code calls
$r-lookup_uri to check on the content type of the file being requested,
which, according to the mod_perl cookbook, forces the subrequest back
through the Access and Auth stages (recipe 3.15, pp. 114-116).
if ($r-lookup_uri($r-uri)-content_type =~ /image/) {
return Apache::DECLINED;
}
that seems like a lot of processing in this particular case - I'd be more
tempted to use that for _other_ URIs rather than the current URI. isn't it
just easier to not configure your access handler for image directories?
though I suppose that you have a reason for doing it like you are :)
as an aside, if you're using mod_perl 1.0 and feeling adventuresome, you
can actually call mod_mime's MIME checker routine on demand, then check
$r-content_type on the current request. see recipe 8.9 in the cookbook, or
the code
http://www.modperlcookbook.org/code/ch08/Cookbook/MIMEMagic.pm
:)
oh, and I suppose that you could always use the
File::MMagic-new-checktype_filename($r-filename)
bit instead of the full lookup as well and still come out ahead.
--Geoff
[ANNOUNCE] Apache::Clean-2.02b
The URL http://www.modperlcookbook.org/~geoff/modules/Apache-Clean-2.02b.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Clean-2.02b.tar.gz size: 6334 bytes md5: 55402e3e753599e56a74204b3e8649c6 this is a preliminary port of Apache::Clean over to mod_perl 2.0. in particular it uses the (current) implementation of Apache 2.0 output filters via the mod_perl 2.0 streaming filter API. so, if you're looking for an example of mod_perl 2.0 code without Apache::compat, or a working example of an output filter, this module has lots of good stuff in it - check out both the module code itself as well as the My::* modules in the test suite. it also uses Apache::Test to run live tests, so it's a good example of how to do that as well. This release also (hopefully) is intelligent enough to install relative to Apache or Apache2, depending on how you built mod_perl 2.0, so if you're trying to create a mod_perl 2.0 package, see the Makefile.PL. anyway, feel free to email me with questions or installation problems (after reading the INSTALL document, of course :) --Geoff from the README: NAME Apache::Clean - interface into HTML::Clean for mod_perl 2.0 SYNOPSIS httpd.conf: PerlModule Apache::Clean Location /clean PerlOutputFilterHandler Apache::Clean PerlSetVar CleanLevel 3 PerlSetVar CleanOption shortertags PerlAddVar CleanOption whitespace /Location DESCRIPTION Apache::Clean uses HTML::Clean to tidy up large, messy HTML, saving bandwidth. Only documents with a content type of text/html are affected - all others are passed through unaltered.
Re: mod_perl Cookbook example
ASHISH MUKHERJEE wrote: Hello! I was trying Recipe 11.3 from the mod_perl Cookbook (Cookbook::Timer). Does this measure real download speed or does it merely measure server processing time? well, it measures the time that it takes Apache to complete the response. this is dependent on a number of factors, such as the speed of your server as well as the end-user connection speed. I understand it takes the time diff between the PostReadRequet and Logging stages. Is the LogHandler phase entered only once the response has fully reached the client? as many log handlers are run as are configured but yes, it runs after the client has received the response. in reality, the connection to the client is still open, so the client may think there is more data coming, but there isn't. HTH --Geoff
Re: internal_redirect and returns
[snip]
I use this subroutine:
sub let_through {
my ($self, $r, $p) = @_;
$r-set_handlers( PerlAuthzHandler = [\OK] );
$r-set_handlers( PerlAuthenHandler = [\OK] );
$p $r-internal_redirect( $p );
return OK;
}
And under some circumstances might call:
return $self-let_through( $r, $login_page );
for instance.
When this happen I find that the page shows ( $login_page ), but the browser
continues to show loading.
I check the error log and find:
message type 0x50 arrived from server while idle
IIRC, you can only call internal_redirect from a content handler. from your
code I suspect that you're not doing that, since it would be too late to
unset the auth phases.
HTH
--Geoff
Re: $r-headers_in-get('Referer') doesn't work with IE
But with IE 6.0 the $r-uri and $r-headers_in-get('Referer') is
different than for NN.
as you're seeing, the Referer header is pretty unreliable due to the
different ways browsers implement it.
you should probably switch to a different method for this, such as
specifying the environment through a PerlSetVar, or maybe passing it around
in a form field, the query string, or extra path info or something.
HTH
--Geoff
Re: PerlCleanupHandler called from default-handler
Tom Murphy wrote: I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: ..a C module has to specifically want this processing to occur-it is not called automatically. well, what we said is true, but you're reading it the wrong way :) basically, all of the Perl*Handler directives - from PerlPostReadRequestHandler to PerlCleanupHandler - can be thought of as parts of the request cycle. however, this is true for all but the PerlCleanupHandler, which really isn't part of the request cycle - mod_perl just makes it look that way. what's really happening is that mod_perl is hooking your Perl handler into the per-request cleanup that Apache offers all C modules (mod_perl included). so it _should_ be called for every request it is configured to run for (should being highly caveated - people have reported that _sometimes_ this doesn't really happen). understanding that is A Good Thing. however, it's not going to help you very much here :) How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. if the PerlLogHandler doesn't get called then you probably have a configuration problem. both of these can exist on their own, outside of a container. something like PerlLogHandler NC::LogHandler Location foo ... if that doesn't show your log handler running then you need to check your error log for errors and make sure your handler compiles under perl -cw or something - if the log handler errors out, you really can't see it unless you look. of course, all this assumes that you built with EVERYTHING=1 - check Apache::Status to make sure. another thing you can try if that doesn't work out is compiling a debugging mod_perl (PERL_DEBUG=1 and PERL_TRACE=1 when building) and set PerlSetEnv MOD_PERL_TRACE on and watch the verbose output. HTH --Geoff
Re: Override Authentication for one sub directory
Scott Alexander wrote: Hi, I'm using Apache-AuthCookie-3.04 for authentication I have a protected directory with 10 sub directories, one directory needs to be open to any user. I could write 10 Directory /usr/local/systems/work/directory_1 or use a PERL section in the conf file to create the 10 directory directives. Can I override the settings for one directory somehow? So any user with no login or password will get in. Actually I don't even want the login prompt to appear. we talk about this in the cookbook - recipe 13.5. basically, you need to disable authentication for the directories in question. see http://www.modperlcookbook.org/code/ch13/Cookbook/PassLocalIP.pm for the example from the book, which disables auth phases for allowed IPs. also keep in mind the Satisfy Any directive, which is what you probably should use if you're thinking about IP based stuff :) HTH --Geoff
Re: How to avoid loss of POST data in a good way?
Frank Maas wrote: Hi, Excuse me for this question that is, without question, due to my newbie- ness, but I am against a wall here. I am creating a website that is running under mod_perl and using several handlers of the chain. The website uses the POST method to send form data. I first used Apache::Request-new() in all handlers, but that made that I lost the posted data after its first use. OK, this was somewhere in the manuals and books and I changed to instance(). My problem begins when I use CPAN or other already-made modules that seem not to respect this and again the posted data got lost. I have an experimental module that may address your concerns: http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz it's not documented, but really all you do is replace Apache::Registry with Apache::CachePOSTRegistry in your httpd.conf then make sure you use Apache::Request-instance() inplace of new(). it's not a complete solution, but it solves the problem of when you want to use POST data throughout the request but you need to use CGI.pm or some other legacy script for the content phase. there is some additional information near the end of this talk http://www.modperlcookbook.org/~geoff/slides/ApacheCon/oo-mod_perl-printable.ppt.gz HTH --Geoff
Re: help with dl_install_.al error please
Warren Pollans wrote: Hi Folks, I still need help with this. Which module is responsible for putting dl_install_.al in auto/DynaLoader? Dynaloader is there. you might want to ask this question over on [EMAIL PROTECTED], where there are people who specialize in the nuances of OS X. truthfully, I'm not sure where this could be originating from - the dl_* functions are all DynaLoader specific ones and part of it's internal magic. sorry. --Geoff
Re: mod_perl Developer's Cookbook
[EMAIL PROTECTED] wrote: On 27 Feb 2003 at 11:35, Gazi, Nasser (London) wrote: A question about mod_perl Developer's Cookbook by Young, Lindner and Kobes: Is this book still relevant and worth buying for mod_perl2 ? (I'm about to dive into web development using Apache/mod_perl and intend to go straight to mp2). you can read our official statement on this at our website http://www.modperlcookbook.org/modperl2.html the thing I'm finding about mod_perl 2.0 is that it exposes much more of the raw Apache API than mod_perl 1.0 did, so you really need to think more about what Apache is doing under the hood than you did before. in this sense, the Cookbook should help, since that's the attitude we were taking there all along - you'll understand mod_perl better if you understand Apache. whether you're talking about Apache 1.3 or 2.0, most of the underlying Apache fundamentals are the same (after all, it's still HTTP). however, the Cookbook does not have any mod_perl 2.0 specific examples. you'll have to go to the docs for that. http://perl.apache.org/docs/2.0/ Thanks, NG The underlying principles remain the same. And I happen to know that Geoff Young is writing some articles (for perl.com?) that highlight the differences between the two systems using examples from the Cookbook. yes, you will probably see some mod_perl 2.0 stuff on perl.com over the next few months (perhaps just weeks), but covering all the differences will be a slow process (at best). --Geoff
Re: Authorization question
Jean-Michel Hiver wrote:
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r-is_intial_req())
I've decided that the
return DECLINED if $r-is_inital_req;
bit is a bad idea. after a few hours debugging an authorization
application, I realized that this does nothing but cause problems - if you
DECLINE a subrequest then it's picked up by mod_auth which, if you're not
configured for flat file auth (in addition to your custom auth), mod_auth
will return AUTH_REQUIRED (or worse).
you may want to
return OK if $r-is_inital_req;
but DECLINED is almost certainly a bad idea.
use Apache::Constants (:common);
my $subr = $r-lookup_uri('/new/request/?foo=bar');
my $status = $subr-status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
I'd change that to
my $ok = $status == HTTP_OK ? 1 : 0;
since there are lots of other things that can be thrown other than
AUTH_REQUIRED - for instance FORBIDDEN from an access handler.
we talk about this in Recipe 3.15 in the Cookbook (which came up yesterday,
so see the archives for where you can find it for free).
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
unfortunately, no - GET is hardcoded in Apache:
API_EXPORT(request_rec *) ap_sub_req_lookup_uri(const char *new_file,
const request_rec *r)
{
return ap_sub_req_method_uri(GET, new_file, r);
}
and by the time you get the subrequest object back, it's too late to call
$sub-method('POST'). of course, theoretically GET and HEAD should be
equivalent :) but I see your point. I guess there's no way around that in
this case.
--Geoff
Re: Authorization question
but DECLINED is almost certainly a bad idea. What was the idea behind return DECLINED if $r-is_inital_req; in auth handlers in the first place? I think it stems from the Eagle book, thus from Doug, but I'm not sure - I can't remember exactly. it was probably an attempt to reduce overhead for subrequests when authentication is expensive (say, a DB query) and you don't really care about whether lookups are authenticated or not. I tried to word it carefully in the book, saying using it depends on what you want to do in your application. clearly if you want to depend on proper authentication for lookups, then you don't want to use is_initial_req() logic at all. it wasn't until after it was too late that I realized DECLINED is problematic. my own particular problem with it was with the subrequests that mod_dir makes - IIRC, on a protected directory returning DECLINED on the subrequest really mucks things up. HTH --Geoff
Re: Problem headers_out
Udlei Nattis wrote:
Hi all
Why i have problem?
$cookie1 = new CGI::Cookie(
-name = 'sessid', -value = $session-id());
$r-headers_out-{'Set-Cookie'} = $cookie1;
[snip]
Can't locate
object method STORE via package APR::Table at
/export/eShop/lib/eShop/Web/Shop/index.pm line 30.
if i remove $r-headers_out-{'Set-Cookie'} = $cookie1;
you need to
use APR::Table;
in your script.
HTH
--Geoff
Re: subrequest-run() doesn't send HTTP headers
[EMAIL PROTECTED] wrote:
Hello list,
i'm trying to run a subrequest from within
a mod_perl content handler. The subrequest
is build from the request's 'lookup_file()'
method. Unfortunately, when i invoke the
'run()' method of the subrequest, no HTTP
headers are sent (even so the documentation
from 'Writing Apache Modules' claims that 'run()'
... will do
everything a response handler is supposed to,
including sending the HTTP headers and the
document body.
... you must not send the HTTP header and
document body yourself ...
well, the Eagle book is a little out of date here
http://marc.theaimsgroup.com/?l=apache-modperlm=96687764724849w=2
subrequests do not include headers, so if you use $sub-run() to send the
subrequest to the client you are required to send headers yourself.
to alter this behavior, use $sub-run(1).
see Recipe 3.16 in the Cookbook, which is available for free from Sams:
http://www.samspublishing.com/catalog/article.asp?product_id={B95F1178-BE9D-43A8-8061-6E351400EF7F}
HTH
--Geoff
Here's a short test case:
sub handler {
my $req = shift;
my $filename = /tmp/sample.html;
my $sub = $req-lookup_file($filename);
$status = $sub-status;
if($status == 200)
{
$ret = $sub-run;
}
return ret;
}
Furthermore, if the filename given to 'lookup_uri()'
points to a directory, $sub-status will return '200'
but '$sub-run()' will return '301' (which is o.k. since
the filename should end with a '/' ...).
Any ideas?
Raf Mattes
Re: subrequest-run() doesn't send HTTP headers
to alter this behavior, use $sub-run(1). see Recipe 3.16 in the Cookbook whoops, that was supposed to be 3.15. --Geoff
Re: subrequest-run() doesn't send HTTP headers
subrequests do not include headers, so if you use $sub-run() to send the subrequest to the client you are required to send headers yourself. which i can't, since i have no idea about the mime-type etc. of the file ;-/ yes you do - the subrequest found out for you :) $r-send_http_header($sub-content_type); to alter this behavior, use $sub-run(1). Ah, thank's a _lot_, that did it. Now, the only question is: why isn't that documented? um, it is documented... if you have the Cookbook :) --Geoff
Re: Redirects: relative vs absolute
Grant McLean wrote:
I've seen a number of code examples for redirects which output a
root-relative URI in the Location header. Eg:
Location: /images/item1.gif
Although browsers seem to accept this and do 'the right thing', the
HTTP RFC seems to be pretty clear that the Location header must be
an absolute URI. Am I reading it wrong?
no.
Is there an easy way to get the absolute URI of the current request
to use with Apache::URI-parse to translate a relative URI to
absolute?
I have managed to get the hostname, port number and path components
individually from the request object and paste them together but
it's all a bit messy.
to generate a URI that points to the same server as the current request it's
best to use Apache::URI methods, which are pretty easy.
my $uri = Apache::URI-parse($r);
$uri-path('/some/new/document.html');
my $absolute_uri = $uri-unparse;
note that calling path() (or any other method) is optional - you don't need
to change anything in order to unparse() the URI and get an absolute URI back.
Apache::URI::parse() can take an optional second argument, which it will
then parse and use as the base for the URI (in place of the current request).
HTH
--Geoff
Re: mod_perl 2.0 question about $r-connection-auth_type
I've just about got the Apache::AuthCookieDBI to work with Apache 2.0.44 mod_perl 1.99_09-dev, but I ran into a problem with the $r-connection object not having auth_type or user defined. The $r-auth_type work just fine. Are these the same reference? What should I look for, or use? [snip] Geoff is working on the proper fix for your original problem. When that's done please check that test again. (see the dev list for developments) the fix has been committed, so you should be good to go based on the discussions we had over on dev@. remember, we added a new method, so you'll have to build mod_perl from CVS and make realclean before building if you want to pick up the new method. lemme know how it goes. --Geoff
Re: Trouble using dir_config for PerlSetVar inside Perl section
Larry Leszczynski wrote:
Hi all -
I'm having trouble using server-dir_config in my startup.pl to read
variables set by PerlSetVar inside a Perl section. I'm using Perl 5.6.1,
Apache 1.3.27, and mod_perl 1.27.
[snip]
and this does not work either:
Perl
push @{$Location{/}-{PerlSetVar}}, [CFG, /path/to/file];
$PerlRequire = startup.pl;
/Perl
It seems like this should work, right?
you may be running into an odditity of PerlSetVar. internally, mod_perl has
logic to merge per-server and per-directory PerlSetVar attributes, doing it
itself instead of relying on Apache. while this is good under most
circumstances, I think you've uncovered someplace where it doesn't work as
well as you'd like.
what may be happening is that your dynamic configuration may be putting your
PerlSetVar into a per-directory scope instead of a per-server scope, since
your config is now in a Perl section. meaning, Apache-server-dir_config
is (rightfully) empty because now your configuration is in
Apache-request-dir_config. of course, you can't get at $r-dir_config at
startup, so you're pretty much SOL.
try looking at $r-dir_config('CFG') in a request and see if your value is
there. if it is, then I guess my theory is right, and there is little that
can be done about it.
HTH
--Geoff
Re: Apache::Module installation issues
dorian wrote: I don't remember what was the outcome of the patch I've posted a long time ago. I sent it after having the same problem. ah, so it's actually a problem with the mod_perl distribution then? well, maybe not. try this patch http://marc.theaimsgroup.com/?l=apache-modperl-devm=98295430720401w=2 as you can see from the rest of the thread, doug applied it but it looks as if Apache::Module hasn't had a release since then. HTH --Geoff
Re: cvs commit: modperl-2.0 Changes
+package Apache::Connection;
+
+# auth_type and user records don't exist in 2.0 conn_rec struct
+# 'PerlOptions +GlobalRequest' is required
+sub auth_type { Apache-request-auth_type }
+sub user { Apache-request-user }
+
1;
__END__
I think this may need a bit more thought (or at least more explanation).
in 1.0 there is both $r-auth_type and $c-auth_type, and they have
different meanings.
$r-auth_type represents the AuthType from the config (via
r-per_dir_config). when you get $r-auth_type, you're asking what kind of
authentication is configured for the request.
$c-auth_type is populated by authen handlers, after the user has been
authenticated, with whatever authentication method was used. I'm not sure
about the history of this, but I suppose in theory it is possible for a
client to request Digest auth, but the server fall back to Basic.
at any rate, I don't know how the current 2.0 or 2.1 aaa stuff handles this
difference, if at all, but we (well, I :) need to be clear on how that works
before agreeing that $r-connection-auth_type in Apache::Compat is the same
as $r-auth_type.
--Geoff
Re: source code appears as text listing in browser
Alois Treindl wrote:
I tried to follow instruction in mod_perl developer's cookbook to move
exitings CGI script to mod_perl.
What happens is that the browser lists the source code of my CGI
scripts, instead of excuting them,
what this means is that the normal Apache handler that sends static content
(such as .html files and images) is serving your pages instead of mod_perl -
a typical problem that usually just boils down to a misconfiguration.
when I create a special mod_perl
directory with this configuration.
PerlModule Apache::PerlRun
Alias /perl/ /www/atl/cm/
PerlTaintCheck on
PerlSetVar Debug 1
Location /perl
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
PerlSendHeader On
Order deny,allow
Allow from all
/Location
the easiest way to proceed is to do essentially what the other poster said.
I would start by copying your cgi-bin configuration in your http.conf
(namely, the Location container and associated Alias directive) and change
it to perl-bin. then check to see whether a simple script behaves the same
under /cgi-bin/ and under /perl-bin/, for example this env.cgi:
#!/usr/bin/perl
print Content-type: text/plain\n\n;
print map {$_ = $ENV{$_}\n} keys %ENV;
at this point, /perl-bin/env.cgi should show GATEWAY_INTERFACE should be
CGI/1.1, since you're still under mod_cgi.
anyway, after you get your cgi-bin working in the new location, then try to
port the config to mod_perl. first replace
SetHandler cgi-script
with
SetHandler perl-script
PerlHandler Apache::PerlRun
and see what happens - you may have enough to run the scripts under mod_perl
with that step alone. try /perl-bin/env.cgi - under mod_perl,
GATEWAY_INTERFACE is CGI-Perl/1.1 and MOD_PERL is set to something true.
if you're getting errors at this point, check the error_log and try to
resolve any - mod_perl is pretty descriptive most of the time. you may need
to add PerlSendHeader to get your scripts where you want them, but it's not
required for the above basic steps to get a working config.
lemme know if this helps.
--Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r-status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? well, Apache::Registry started out as a mod_cgi emulation layer, trying to speed up legacy mod_cgi scripts without alteration. personally, I think that concept is flawed because we all know that many legacy CGI scripts are poorly written, so you need take special measure to not fall into the numerous documented Registry traps. not to mention that Registry doesn't handle HEAD requests properly (in 1.0), if you read POST data elsewhere you're SOL in your CGI script, etc. but, ok, say you have your CGI emulation layer - that's one facet of Registry. however, Registry also acts as a dispatch mechansim for people wanting to use the mod_perl API without writing separate handlers for each bit of functionality - since you get $r passed in automatically, or can retrieve it via Apache-request on your own, you are fully free to use Registry this way and many people do. fiddling with $r-status is _only_ possible when Registry is used in this way - there is no mod_cgi equivalent way to set that part of the request record (that I know about, anyway :) for people who want to use the mod_perl API to, say, return REDIRECT, there needs to be some mechanism to allow them to do so, and the $r-status hack has traditionally served this purpose. (one of) my points before was that with 2.0 and the Cooker idea, we really can (and ought to) have two versions of Registry to accomodate these two needs - people who just want faster mod_cgi (and Registry returns OK or SERVER_ERROR) and people who want the mod_perl API (and Registry returns the script return code). separating out the two classes of users will probably make the Registry logic much easier and cleaner. just my $0.02. --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-devm=101240123609773w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r-headers_out(Location = '/foo'); $r-status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r-status(REDIRECT); return OK; and $r-status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r-status() bit was always a hack - nobody is supposed to fiddle with $r-status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. --Geoff
[ANNOUNCE] mod_perl Developer's Cookbook available in Polish
for our native Polish speakers (as well as the archives), the Polish translation of the mod_perl Developer's Cookbook appears to be available and shipping. http://helion.pl/ksiazki/modpkp.htm I haven't seen it yet (nor do I read Polish) but the above site seems to include a tarball of the code with the comments translated as well. ftp://ftp.helion.pl/przyklady/modpkp.zip and, as a reminder, if you want the code in English, it is always available from our website http://www.modperlcookbook.org/code.html nice work Przemyslaw! --Geoff
Re: Stacked Handlers Execution Chain
however, DONE is special - it indicates that all content has been sent and the request cycle should proceed straight to the logging phase. from a handler perspective, DONE behaves the same as an error code - it terminates the request cycle. But the book doesn't say that DONE does break the chain, though it does. an error in a book? I'm shocked. :) I suspect that 1.0 logic handled DONE automatically - DONE was captured and passed back to Apache, which took appropriate action. and I suspect this is what you found in 2.0, since you test for DONE but didn't handle it explicitly. It works exactly the same in 2.0 as in 1.0 (using the current cvs ;), the chain is aborted on !(OK || DECLINED). Any return codes are passed further to Apache. sounds proper to me. nice work. --Geoff
Re: Stacked Handlers Execution Chain
Helmut Zeilinger wrote: Hi, i am using mod_perl 1.99_08. I have two mod_perl handlers: ... PerlResponseHandler Test::handler0 Test::handler1 ... How can i brake the execution chain between handler0 and handler1? Whatever i try as handler0 return value (OK, DECLINED, FORBIDDEN, 404) the handler1 is still executed. The documentation says, that any value except DECLINED should do that. it probably should say that OK, DECLINED, or DONE will allow the chain to continue. anything else ought to immediately terminate the chain - if not, it's probably a bug. you might want to see if there is a difference between returning FORBIDDEN, NOT_FOUND, and SERVER_ERROR (well, their 2.0 equivalents, anyway), just to help track things down. --Geoff
Re: Stacked Handlers Execution Chain
First of all let's clear up the 1.0 side:
Quoting the eagle book:
The exception to this rule [all handlers will run] is if one of
the handlers in the series returns an error code (anything other than
OK, DECLINED, or DONE)
Though the code does *not* check for DONE:
mod_perl.c:1375
if((status != OK) (status != DECLINED)) {
...
return status;
}
so where is the bug? In the book or the code?
well, OK, DECLINED, and DONE are all success codes - everything else
is an error and goes to the error document cycle.
however, DONE is special - it indicates that all content has been sent
and the request cycle should proceed straight to the logging phase.
from a handler perspective, DONE behaves the same as an error code -
it terminates the request cycle.
I suspect that 1.0 logic handled DONE automatically - DONE was
captured and passed back to Apache, which took appropriate action.
and I suspect this is what you found in 2.0, since you test for DONE
but didn't handle it explicitly.
kudos, stas, for always taking care of all the 2.0 stuff.
--Geoff
Re: Object Handlers internal_redirect
So I converted Util::Tour::Translate's handler into a regular non object
handler and everythings works fine. I would rather use object handlers but
this doesn't seem possible if a content handler is performing an
internal_redirect which might invoke that handler.
this has been reported before - it's in the archives someplace I'm sure - I
just haven't had the time to investigate it. I suspect that it needs a
patch similar to one I have lying around but that doug wasn't too interested
in putting into core due to some potential side effects. when I get a
moment, I'll try and follow up on it.
Can somone shed some light on this for me please.
Richard.
p.s. I didnt yet try converting Util::Tour::Banner into an object handler.
Is it neccessary for all handlers in a chain to be either object or regular
but not a mix?.
it shouldn't be, no.
some things to try are changing your config to
PerlModuleUtil::Tour::Translate
PerlTransHandler Util::Tour::Translate
that might work out a bit better (though I suspect you'll then get $r only
in your handler instead of $self and $r).
you might also want to try
sub handler : method {
...
}
instead of sub handler ($$) {
...
}
and see if that changes anything (though I doubt it).
HTH
--Geoff
Re: rfc: new filtering APIs
Stas Bekman wrote:
Geoffrey Young wrote:
Finally, other than add/remove filters APIs which we have talked
about, what other APIs do you want for filters?
is there an interface to filter_init?
see the discussion on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9673
or CHANGES file for a description of why it was added.
this API may be crucial to mod_perl developers who want to handle
conditional GET requests properly with their filters.
First of all you can always do:
unless ($filter-ctx) {
# filter is called for the first time
# and this code won't be run only once
$filter-ctx(1);
}
so if you want to do something once, or e.g. remove yourself you can do
it in this block. So it seems to be similar to filter_init. Or am I
wrong here?
no, you need the real filter_init hook.
the issue here is that default_handler has meets_condiditions() logic in it,
so it makes decisions about whether or not to send content down the chain.
this is generally bad for filters, since they may have their own criteria
for determining what gets involved in making that decision - if
default-handler doesn't have all the information, it can return NOT_MODIFIED
when the filter would have chosen to re-modify the content (based on, say,
the fact that the version of the code has changed so it does things
differently now).
filter_init is a hook that runs code before any handlers run, I suspect for
adding calls to update_mtime() and other similar things.
I agree that having a dedicated filter_init seems to be
cleaner and probably more efficient.
If filter_init is wanted, how should it be set by the Perl code? Using
an optional second argument to the filter configuration?
PerlOutputFilterHandler MyFilter MyFilter::init
I would want at least a real-time interface for this, something similar to
$filter-init(sub {shift-update_mtime($package_mtime)} );
sub handler {
...
}
it's important that the filter be able to insert this logic itself without
relying on httpd.conf stuff. that makes the filter self-contained and a bit
more DWIMmy. of course, the subroutine/coderef would have to run on each
request, similar to $r-register_cleanup, just at the other end.
Also can you please give me some useful test I can play with? Probably
one of the examples from your book will do ;)
I'm working on something now, but without a tie into filter_init there's not
much to show :)
if you come up with the interface, I'll write the tests to make sure it does
what we need.
--Geoff
Re: [mp2] Conflicting instructions in docs?
I'm confused. Where's the quick answer to whether or not I should use threads? I'm on FreeBSD 4.7. you shouldn't need -DUSETHREADS unless you plan on using the threaded MPM you can use your normal perl with --with-mpm=prefork (at least I think so :) --Geoff
