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

RE: remove dot segment

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>
Message-Id: <20041119111209.8C618189AA@danka.ii.fmph.uniba.sk>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:35 GMT