You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2003/06/02 03:23:10 UTC
2.0 bug? trailing / redirect problem in mod_dir
http://httpd.apache.org/docs-2.0/mod/mod_dir.html says:
A "trailing slash" redirect is issued when the server receives a
request for a URL http://servername/foo/dirname where dirname is a
directory. Directories require a trailing slash, so mod_dir issues a
redirect to http://servername/foo/dirname/
However if you have a non-trailing / config to be handled by
non-default handler, e.g.:
<Location /foo/dirname>
SetHandler perl-script
PerlHandler Apache::HelloWorld
</Location>
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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by Stas Bekman <st...@stason.org>.
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
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 <st...@stason.org> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
Stas,
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.
Bill
At 01:05 AM 6/2/2003, Stas wrote:
>Justin Erenkrantz wrote:
>>--On Monday, June 2, 2003 11:23 AM +1000 Stas Bekman <st...@stason.org> 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>
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Monday, June 2, 2003 11:23 AM +1000 Stas Bekman <st...@stason.org>
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, June 2, 2003 11:23 AM +1000 Stas Bekman <st...@stason.org> 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? -- justin
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> http://httpd.apache.org/docs-2.0/mod/mod_dir.html says:
>>
>> A "trailing slash" redirect is issued when the server receives a
>> request for a URL http://servername/foo/dirname where dirname is a
>> directory. Directories require a trailing slash, so mod_dir issues a
>> redirect to http://servername/foo/dirname/
>>
>> However if you have a non-trailing / config to be handled by
>> non-default handler, e.g.:
>>
>> <Location /foo/dirname>
>> SetHandler perl-script
>> PerlHandler Apache::HelloWorld
>> </Location>
>>
>> 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.
>
>
> There is one more problem with this issue. The path_info record is
> always ''.
Justin suggested to:
1) stop mod_dir from doing a redirect if it isn't the handler and
2) fix SetHandler by having core_override_type match the 1.3 semantics by
not mucking with dirs
and then the second issue I've mentioned above will be automatically resolved.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 2.0 bug? trailing / redirect problem in mod_dir
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> http://httpd.apache.org/docs-2.0/mod/mod_dir.html says:
>
> A "trailing slash" redirect is issued when the server receives a
> request for a URL http://servername/foo/dirname where dirname is a
> directory. Directories require a trailing slash, so mod_dir issues a
> redirect to http://servername/foo/dirname/
>
> However if you have a non-trailing / config to be handled by
> non-default handler, e.g.:
>
> <Location /foo/dirname>
> SetHandler perl-script
> PerlHandler Apache::HelloWorld
> </Location>
>
> 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.
There is one more problem with this issue. The path_info record is always ''.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com