- From: Martin Balaz <balaz@ii.fmph.uniba.sk>
- Date: Fri, 19 Nov 2004 11:12:06 -0000
- To: <uri@w3.org>
- Cc: "'Roy T.Fielding'" <fielding@gbiv.com>
OK, let see it from the other view:
> file:/x/..//y
> file:x/..//y/
URI Reference: ..//y
Base URI: file:/x/
Target URI: file://y
URI Reference: ..//y/
Base URI: file:x/
Target URI: file:/y/
Both URI References and also both Base URIs are valid. Although they are
valid, in both cases the remove_dot_segments function has not intuitive
results.
I would also expect that "x/y//../z" is equivalent with "x/z" instead of
"x/y/z" (Base URI = "x/y//", URI Ref. = "../z").
What to do in those cases? I think that we can't assume that the input for
the remove_dot_segments function (by ex. /x/..//y, x/..//y/ or "x/y//../z")
is in general valid path.
Martin
-----Original Message-----
From: uri-request@w3.org [mailto:uri-request@w3.org] On Behalf Of Roy
T.Fielding
Sent: Friday, November 19, 2004 7:58 AM
To: Martin Balaz
Cc: uri@w3.org
Subject: Re: remove dot segment
On Nov 18, 2004, at 9:17 AM, Martin Balaz wrote:
> I would like to discuss one old problem of the remove_dot_segments
> function,
> which is not yet solved as I know.
>
> Following URIs are valid with the respect to the latest rfc2396bis:
No, they are allowed by the syntax. They are not valid.
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) for indicating relative position within the
hierarchical tree of names. This is similar to their role within
some operating systems' file directory structure to indicate the
current directory and parent directory, respectively. However,
unlike a file system, these dot-segments are only interpreted within
the URI path hierarchy and are removed as part of the resolution
process (Section 5.2).
It doesn't matter what is the result of processing
> file:/x/..//y
> file:x/..//y/
because those are not valid file URIs.
....Roy
Received on Friday, 19 November 2004 11:12:13 UTC