Stas Bekman wrote:
It looks like besides testing the API we also may want to test some common techniques. e.g. for one of the recent problem reports on the modperl list, I wrote this rewrite test. Should I commit it? If so, should we start a new category of tests for common techniques. Not sure what's the best short name, 'cooks', 'recetas' or 'fill in some short name'?
what about just 'user'?
and what's the mnemonic here? Really, this could be anything, I'm just trying to come up with the name that when next time we need to add a new test we don't need to thinking for too long to figure out which group to add it to.
In any case, shell we add that test?
BTW, Apache now requires you to set $r->filename() if you return
Apache::OK from the transhandler.
well, that's true but I think your comment is a bit misleading.
returning OK from a trans handler _means_ that you have set r->filename. in other words, Apache is both expecting and enforcing that r->filename be set by the end of translation. but wait, there's more...
Yes, but it wasn't so in mp1. In mp1 you return OK without setting r->filename and Apache has no problem with that. Hence was my comment.
In this test I simply left for Apache to figure it out, but obviously we get the stat() calls perfomance hit.
the old reason that we used to return OK from a trans handler was to avoid the stat for non-file URIs. however, this stat now happens in map-to-storage, not translation. hence it is core_map_to_storage that throws the "module bug?" warning. well, ok, it's ap_directory_walk, but now that is only called from core_map_to_storage (and a few other modules like proxy and dav).
so, what this means is that if you want to avoid the stat call you need to return OK from a PerlMapToStorageHandler, not the PerlTransHandler. also, in these cases you can skip the PerlTransHandler altogether - there is no benefit whatsoever from returning OK from perl except that it might actually slow you down, depending on how fast the perl is compared to ap_core_translate.
good thing we have a PerlMapToStorageHandler ;)
Yeah, good indeed.
First of all, how about dumping the above into modperl-docs/src/docs/2.0/user/handlers/http.pod? That new phase is completely undocumented (besides mentioning that it exists). And mentioning in the performance chapter that one needs to use PerlMapToStorageHandler to shortcut the stat() calls. I guess with:
PerlMapToStorageHandler Apache::OK
which will work only if all requests are to the virtual namespace. I've changed the test below to do it only for that particular test.
Still it's possible that
$r->filename('');
in transhandler (if you do rewrite the namespace already) is another working solution too, since you need the transhandler, and you don't need to write a maptostorage handler at all.
You suggest to skip the PerlTransHandler completely only when you want to avoid the stat calls, right? You still need it for rewrites.
package TestModules::rewrite;
use strict; use warnings FATAL => 'all';
use Apache::Test; use Apache::TestUtil;
use Apache::RequestRec (); use Apache::RequestIO (); use Apache::URI ();
use Apache::Const -compile => qw(DECLINED OK);
my $uri_real = "/TestModules__rewrite_real"; my $args_real = "foo=bar&boo=tar";
sub trans {
my $r = shift;return Apache::DECLINED unless $r->uri eq '/TestModules__rewrite';
$r->uri($uri_real);
$r->args($args_real);
#$r->filename(''); # make Apache happyreturn Apache::OK; }
sub map2storage {
my $r = shift;return Apache::DECLINED unless $r->uri eq $uri_real;
# skip ap_directory_walk stat() calls
return Apache::OK;
}sub response {
my $r = shift;plan $r, tests => 1;
my $args = $r->args();
ok t_cmp($args_real, $args, "args");
return Apache::OK; }
1;
__END__
<NoAutoConfig>
PerlModule TestModules::rewrite
PerlTransHandler TestModules::rewrite::trans
PerlMapToStorageHandler TestModules::rewrite::map2storage
<Location /TestModules__rewrite_real>
SetHandler modperl
PerlResponseHandler TestModules::rewrite::response
</Location>
</NoAutoConfig>__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
