httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: 2.0 bug? trailing / redirect problem in mod_dir
Date Mon, 02 Jun 2003 23:19:51 GMT
William A. Rowe, Jr. wrote:
> 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 

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 

> Bill
> At 01:05 AM 6/2/2003, Stas wrote:
>>Justin Erenkrantz wrote:
>>>--On Monday, June 2, 2003 11:23 AM +1000 Stas Bekman <> 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
>>>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


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message