From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Saturday, April 07, 2001 3:55 PM
> I think the handling of Location directives, particularly the SetHandler directive
>inside
> a Location directive is broken. Or perhaps it never worked the way I intuit is should
> work. Why should we run directory_walk() if a location_walk() has identified a
>handler
> for the request???
>
> In httpd.conf I have enabled mod_status thusly...
> <Location /server-status>
> SetHandler server-status
> </Location>
>
> Why are we even in directory_walk()???
>
> location_walk() is run BEFORE directory_walk() (see process_request_internal() in
> http_request.c). Seems if we find a handler for the request during the first
> location_walk, we should skip the call to directory_walk(), no? Skipping
>directory_walk
> would avoid the stat calls.
>From the docs http://httpd.apache.org/docs/mod/core.html#location
"<Location> sections are processed in the order they appear in the configuration file,
after the <Directory> sections and .htaccess files are read, and after the <Files>
sections."
and from http://httpd.apache.org/docs/sections.html
"Another note: There is actually a <Location>/<LocationMatch> sequence performed just
before
the name translation phase (where Aliases and DocumentRoots are used to map URLs to
filenames).
The results of this sequence are completely thrown away after the translation has
completed."
> This suggests that perhaps the translate hook for mod_status should identify that the
> request is not a file and set r->filename = NULL. I am looking at Apache 1.3 but
>all this
> discussion should apply to Apache 2.0 as well.
I'm --1 on changing the parsing in 1.3, ever, not even a little. You will _break_ a
ton of
security that was carefully audited in user's environments.
For 2.1 (or 3.0) this nonsense must change. If I say <Location /> SetHandler
SQLSpace-handler
then the entire file-system part of httpd needs to just _disappear_.
This requires a number of non-trivial changes:
. Location parsing must occur before Directory parsing
. Directory walking/parsing must leave the core, and move out to a filesystem module
. When a Location directive contains a DocumentRoot it passes control out of
<location >
into the filesystem <directory > namespace.
. For legacy, a DocumentRoot outside of a <Location > block is parsed as if it were
given in the <Location /> block.
Fortunately, AllowOverrides live only in <Directory > blocks, and will continue to
behave in
the correct manner. The stat for %DocumentRoot%/.htaccess before the /server-status/
location
is tested is always correct if the root of the namespace is a filesystem space. But
it's
entirely non-extensible. I believe (strongly) that we need an additional set of
changes:
. An Overrides hook that handles the parsing for .htaccess files. This is
abstracted away
from it's current residence in dir_walk(). It allows the overriding to be done by
new
Overrides handlers sitting in, say, a DBM rather than in .htaccess files.
. Configuration of the 'Overrides' provider.
. Implicit assumption (for compatibility) that a filesystem space has the .htaccess
Overrides handler if the DocumentRoot was used to map a location (even /) into the
filesystem space.
. No invocation of the Overrides hook when AllowOverrides is set to None.
And the worst change of all, if we are going to allow this shifting from filesystem to
the
URI space, we need the location handler to start recongizing that the namespace
(filesystem)
has mapped a /foo///bar/ location to the /foo/bar/ location, and _STOP_ letting people
walk
around such escaped locations.
None of these changes is simple, and there are no one-liner patches to solve it. It's
a terribly thorny set of problems.
The coming change to parsing will at least assure that the %DocumentRoot% isn't stated
again
once it's canonicalized at startup. Then AllowOverride None should start working much
more
consistently with what you expect, as soon as a directory namespace cache is put into
the
server.
Bill
.
