Re: Status of RFC 1738 -- 'ftp' URI scheme

John Cowan wrote:
> Dan B. scripsit:
> 
>> Try "file://///foo/bar/baz".  ...
> 
> ...
> 
>> Then then the URI path "///foo/bar/baz" represents that pathname
>> (the UNC pathname "\\foo\bar\baz").  (No, I don't recall exactly
>> how the three slashes turns into only two backslashes.))
> 
> A pity; I'd like to see how that works.  It certainly isn't intuitive;
> I would have expected four slashes to work (it doesn't).

There's something non-intuitive about the slash that begins the path
portion of a URI, at least for some URI schemes.

(I haven't checked whether this is part of the URI specification(s)
or is just the (possibly non-conformant) behavior of some tools.)


For example, I was surprised when I found that ftp://U@host/x didn't
refer to the same file as ftp://host/x (at least in Seamonkey (I think)
and a particular FTP server).

I had thought that in both cases the URI path of "/x" would refer to x
in the root directory (because in both anonymous FTP and non-anonymous
FTP, "cd /" would take one to the same directory).

However, the first URI there referred to the file x in the default
directory for user U (the directory in which one would be right after
making an FTP connection).

(I don't recall whether I checked whether ftp://U@host//x referred to
the same thing as ftp://host/x .)


The authority portions of the URIs are different (for the anonymous-FTP
view vs. a user-specified view), so the interpretation of the path
can be different.  And since the initial slash in the URI path is
required (to recognize that the URI has a path component), one can't
give URI paths of "x" vs. "/x" to differentiate between relative FTP
paths of "x" vs. "/x".

However, if the mapping from the URI path to the FTP is defined to
involve stripping off the leading URI path slash, then FTP pathnames
of "x" vs "/x" can be differentiated (as ftp://U@host/x vs.
ftp://U@host//x, respectively).  Apparently, that's how Seamonkey
(and maybe wget) treats it.


The UNC-path URI file://///host/x/x/ seems to be similar.



Hmm. That make me wonder what file:///x would refer to. ("/x" or
"x" relative to the browser/etc.'s working directory.)

(Hmm again:  What about "file:/x" and "file:x"?)



Daniel

Received on Tuesday, 18 January 2011 15:34:17 UTC