Message-Id: <199311292327.SAA03378@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: a better ftp URL
In-Reply-To: Your message of "Mon, 29 Nov 1993 11:34:32 PST."
<93Nov29.113434pst.2732@golden.parc.xerox.com>
Date: Mon, 29 Nov 1993 18:26:14 -0500
> I have a slightly different issue with FTP urls, which is the 'to CD
> or not to CD' question.
>
> For some anonymous FTP servers, given
>
> ftp://host.blah.blah/a/b/c/d/e
>
> you're better off doing a
>
> cd a/b/c/d
> get e
>
>
> while with others, you're better off doing
>
> get a/b/c/d/e
>
> while, for some, you're supposed to do
>
> cd a
> cd b
> cd c
> cd d
> get e
>
>
> Should the FTP URL be able to distinguish between these cases?
absolutely. the url should fully specify the relevant protocol
details, including (for ftp)
USER xxx (probably anonymous)
PASS xxx (probably email address, but sometimes "guest")
ACCT xxx
CWD somewhere (perhaps multiple iterations)
MODE x
STRU x
RETR filename
...else interoperability with non-UNIX ftp servers is lost.
(though it's probably fine to restrict URLs to a subset of ftp that deals
with octet-stream files only.)
Best idea I have had (to retain backward compatibility) is to assume that '/'
is a directory separator...you have to do a separate CWD for each one. so if
the filename portion is a/b/c/d/e you have to do
CWD a
CWD b
CWD c
CWD d
RETR e
But this wouldn't apply to a '/' encoded as %2f. So if the filename portion
of an FTP URL were a%2Fb%2Fc%2Fd/e the client would do
CWD a/b/c/d
RETR e
and for a%2Fb%2Fc%2Fd%2Fe (yeech!) the client would do
RETR a/b/c/d/e
To give a non-UNIX example, a VMS file could have a url of
[.b.c.d]/e.xxx
which would cause a client to do:
CWD [.b.c.d]
RETR e.xxx
Keith