Date: Mon, 19 Dec 1994 21:04:32 +0100
Message-Id: <94Dec19.120345pst.2760@golden.parc.xerox.com>
From: Larry Masinter <masinter@parc.xerox.com>
To: Multiple recipients of list <www-proxy@www0.cern.ch>
Subject: Re: proxies and FTP
I said:
> In the meanwhile, the short answer is that you can't reliably give out
> ftp URLs for sites/files where cwd A; cwd B; retr C isn't equivalent
> to retr A/B/C.
and Adrian Colley replied:
> Surely the meaning of '/' in URLs is to separate logical parts of the
> name? I mean, cwd A; cwd B; retr C would be required by ftp://where/A/B/C,
> but retr A/B/C would be required by ftp://where/A%2FB%2FC.
and gave an example, but then added:
> Of course, no-one does this ;-).
which is why you can't *reliably* give out those kinds of FTP URLs.
That is, I think what we wrote for the URL proposed standard is
unambiguous, but it isn't widely implemented; proxy services are a
class of clients that would have to be retrofitted to match the
standard (or, conversely, have the standard retrofitted to match the
clients.)
I don't think anyone has a strong vested interest in disqualifying
current practice, but it *would* be nice if URL-interpreting-agents
for FTP would actually *not* do the 'GET a/b/c' unless they were
relativley that it was actually equivalent to 'CWD a', 'CWD b', 'GET
c', e.g., by only making the optimization when given a well-known and
appropriate SYST and FTP implementation banner.