httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 2.0 bug? trailing / redirect problem in mod_dir
Date Mon, 02 Jun 2003 13:36:43 GMT

  when is PerlTransHandler evaluated?  Not until the run_handlers() 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.

  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.


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 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

View raw message