W3C home > Mailing lists > Public > uri@w3.org > April 2004

Re: More test cases to be confirmed

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 6 Apr 2004 18:09:24 -0700
To: uri@w3.org
Message-Id: <35A0000A-8830-11D8-9CC7-000393753936@gbiv.com>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC