From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 12:15 PM
> On Sat, 7 Apr 2001, William A. Rowe, Jr. wrote:
>
> > 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.
>
> unfortunately "/foo///bar/" is a different uri from "/foo/bar/", and if
> "/foo" is a mount-point for a handler which takes various options in the
> form of sub-path components then "///bar/" would have 3 components, 2 of
> which are empty.
I concur. The issue is this ... if /foo maps into filesystem space (and none
of the foo/ foo// foo/// or foo///bar URI's map the user back out of filesystem
space) then the location is tested at each of these (and no-ops), and should
finally resolve to location /foo/bar after the filesystem 'accepts' /foo/bar
as the request to serve.
While these are different URI's - the resource they serve results in a specific
URI. Let's use the request for /foo/bar where the (case insensitive) /Foo/Bar
exists... I'm sugesting the tests ought to sequence
<Location /> [Has a DocumentRoot in filesystem space, so...]
<Directory />
<Location /foo> [Isn't overridden]
<Directory /Foo> [Folded to /Foo before testing]
<Location /foo/> [Isn't overridden]
<Directory /Foo/> [Is the FS entity]
<Location /foo//> [Isn't overridden]
<Directory /Foo/> [Corrected to /Foo/ -- we ought to optimize out]
<Location /foo///> [Isn't overridden]
<Directory /Foo/> [Corrected to /Foo/ -- we ought to optimize out]
<Location /foo///bar> [Isn't overridden]
<Directory /Foo/Bar> [Folded to Bar before testing]
Since /foo/bar is accepted as servable by the filesystem space...
<Location /Foo/Bar> [Closing Location test we have today, but as-mapped]
The specifics of what goes on in Directory may change in the context of the
filesystem [unix, samba, win32, os2, netware etc] that we are serving. It
should be pointed out that a fs could _accept_ /foo///bar as semanticly
significant for it's structure.
But in the case that /foo///bar was a location that mapped to server-info,
the final pass would accept:
<Location /foo///bar>
and would never parse <Directory /Foo/Bar> nor correct 'the location'
and test <Location /Foo/Bar> since it isn't in filesystem space.
The counter-argument goes that once we decided that /foo -> /Foo, the user
had no more flexibility, and the <Location /foo/// -> /Foo/> since all of
those elements fell into filesystem space. I'm not strongly bent either way.
We have a long conversation to go before we choose the 'one correct way'
to handle this.
Bill
