[mp2] fun with $r->location

[Dorian Taylor <do...@foobarsystems.com>]

i guess i had never come across it before, but i noticed today, in
an attempt to use $r->location as a prefix for scrubbing path
segments off the front of a request URI, that it's the innermost
<Location> block that matches the URI path and that has a Perl*Handler
in it that is returned, not the one in which the handler was
registered.

i'm curious about what would be a good way of reliably getting at
the value of the proper <Location> block (let's leave LocationMatch,
Files ~ etc out of this for the time being).

consider this (assuming @DocumentRoot@/foo/bar/bitz exists):

<Location /foo>
Options +Indexes +MultiViews
PerlTypeHandler +MyApache::NopHandler
</Location>
<Location /foo/bar>
SetHandler perl-script
PerlHandler +MyApache::NopResponse
</Location>
<Location /foo/bar/bitz>
#whatever, anything
Options +FollowSymlinks
</Location>

suppose MyApache::NopHandler simply outputs $r->location to the
error log, and MyApache::NopResponse outputs the $r->location to the UA.

GET /foo/ yields the listing for /foo/, and NopHandler logs
$r->location to the error log as /foo.

GET /foo/bar yields the results of NopResponse (which just coughs
up its $r->location, /foo/bar), and NopHandler logs $r->location
as /foo/bar, even though it is registered in <Location /foo>.

GET /foo/bar/bitz yields the same results as GET /foo/bar.

how would i reliably get MyApache::NopHandler to only ever emit
"/foo"?

cheers

.dorian

Re: [mp2] fun with $r->location

[Geoffrey Young <ge...@modperlcookbook.org>]

> GET /foo/ yields the listing for /foo/, and NopHandler logs
> $r->location to the error log as /foo.
> 
> GET /foo/bar yields the results of NopResponse (which just coughs
> up its $r->location, /foo/bar), and NopHandler logs $r->location
> as /foo/bar, even though it is registered in <Location /foo>.
> 
> GET /foo/bar/bitz yields the same results as GET /foo/bar.

those are all exactly what I would expect.  remember that for nested
<Location> blocks settings are merged - it doesn't matter that your
PerlTypeHandler is registered to /foo, for the URL /foo/bar it is merged
with <Location /foo/bar> and it is (ultimately) <Location /foo/bar> (and
it's parent configurations) that service the request.

but fear not, you're not alone in not understanding how nested container
directives behave.  but this might help:

  http://httpd.apache.org/docs/sections.html

--Geoff