Stas,
when is PerlTransHandler evaluated? Not until the run_handlers() phase?
Why? It's running during the translate_name phase
Perhaps the simplest is to set the response ->handler to application/x-perl
or something similar after the location walk, such as within map_to_storage or fixups. That would avoid having to add any extra perl-foo inside of the user's httpsd.conf file.
You mean for mod_perl to internally hook into map_to_storage and if the ->handler is DIR_MAGIC_TYPE, set it to the modperl handler, causing mod_dir to skip?
But there is a problem here. How mod_perl get to know if it's supposed to run at all? May be mod_dir is what the user wanted. mod_perl doesn't get the knowledge of whether it was configured as SetHandler for a given location at that time.
Yes, 2.0 isn't consistent with 1.3 in such respects. I hope that this project continues to separate some of these issues to the point where we *ultimately* determine the entire metadata correctly within the process request phase, and the entire data stream within the handler phase.
The internal redirects should probably continue to occur in the process request phase. If we are actually emitting the redirect response to the client in that phase, I can see the value of reverting to 1.3 behavior on the external redirects and moving them back to the handler phase.
Well, that's what we deal with in this thread. mod_dir runs an external redirect...
Bill
At 01:05 AM 6/2/2003, Stas wrote:
Justin Erenkrantz wrote:
--On Monday, June 2, 2003 11:23 AM +1000 Stas Bekman <[EMAIL PROTECTED]> wrote:
it should honour this configuration and not ignore it, issuing a redirect, despite the existence of DocumentRoot/foo/dirname. This is how it worked in Apache-1.3 and appears to be broken in Apache-2.0.
Apache 1.3 gives precedent to directories over locations. I'm not clear how you reached that conclusion, but I just tested it on 1.3 (and 2.0), and in the presence of a collision, the directory is returned not the location.
What you might be suspicious of is that 2.0 may invoke the handler associated with the location and not the default handler. In 1.3, mod_mime would not run the SetHandler line if it was a directory - see mod_mime.c:626. However, in 2.0, the SetHandler enforcement was taken out of mod_mime and placed in core_override_type in core.c:3222 which *does* act upon a directory. Therefore, under 2.0, the SetHandler line is enacted, where in 1.3, it was not.
I think the proper thing may be to have core_override_type follow the 1.3 semantics and punt on a directory. But, I'm not sure. Thoughts?
I did some more digging and tracing and the problem seems to be as follows:
in apache 1.3 mod_dir was a running as a response handler, allowing other response handlers to be inserted before it and thus override it. For example mod_perl was registering itself to handle DIR_MAGIC_TYPE and was overriding mod_dir if there was r->handler set to "perl-script".
in httpd 2.0, mod_dir is running as a fixup handler. So if a module wants to override the behavior as in 1.3 it can't to do that. Moreover fixups are RUN_ALL, so it won't be very helpful to even insert an earlier handler it this phase.
The only workaround so far is to shortcut the trans handler (or could shortcut mod_mime's typemap as well), but that's ugly and inconsistent with apache 1.3.
PerlModule Apache::RequestRec PerlTransHandler \ 'sub {shift->uri eq "/hello-world" ? Apache::OK : Apache::DECLINED }' <Location /hello-world> SetHandler perl-script PerlResponseHandler Apache::HelloWorld </Location>
--
__________________________________________________________________ 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
