- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 6 Apr 2004 18:09:24 -0700
- To: uri@w3.org
On Thursday, February 19, 2004, at 07:38 PM, Adam M. Costello wrote: > Apparently the intention of the new draft is to revoke this > indeterminacy and settle on a single behavior (discard initial ".."), > but of course there will be existing implementations that made a > different choice. Discarding initial ".." is consistent with typical > Unix behavior: /../../../etc/passwd is equivalent to /etc/passwd on > most > Unix-like platforms. And Windows-based platforms, which is why most implementations either remove those segments or leave themselves vulnerable to security holes. > I agree that the current draft would have the result be "foo:/b/c", and > I fully agree that "./b/c" should be treated as equivalent to "b/c", > especially since we need to use this equivalence when a segment > contains > a colon. Here's a motivating example: > > The document foo:a wants to link to the document foo:b:c/d. It can't > use the relative reference "b:c/d" because the b: looks like a scheme. > If it uses the absolute reference "foo:b:c/d" then it won't be easily > movable to another scheme (like foos, the secure version of foo). What > it really wants to use is "./b:c/d" (as suggested in RFC-2396), but > the current draft will resolve that to "foo:/b:c/d", which is not the > target. That is an excellent argument -- I'll change the algorithm so that it treats non-rooted paths as a root label rather than adding "/" to the front. > Another surprising result: > > Base: "foo:a" > Ref: "foo:." > Result: "foo:." > > I would expect the result "foo:" (empty path). > > Similarly: > > Base: "foo:a" > Ref: "foo:.." > Result: "foo:.." > > These last two cases are the only cases where remove_dot_segments fails > to live up to its name. Those were intentional -- to avoid mucking with URIs that avoid using "/" at all. *shrug* ....Roy
Received on Tuesday, 6 April 2004 21:10:47 UTC