- 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