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

On 1/18/2011 9:31 AM, Dan B. wrote:
> 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.

This sounds like a bug in seamonkey, you should see if others behave
similarly.  The URI definition is pretty strict that /path is absolute
in scheme://user@host/path, anything else would be nonsense, as you note.

BUT it's entirely possible the ftp server you are looking at jails users
to a specific directory, in which case seamonkey is working just fine.
Jailed FTP users see a tree specific to their user account, and however
one looks at the ftp scheme, it should be noted that for some schemes,
the //user@host component may vary between user contexts.

Received on Tuesday, 18 January 2011 18:04:46 UTC