Subject: Re: [1.4beta/i386 boot floppy] ftp url parsing
To: Todd Vierling <email@example.com>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 04/28/1999 00:03:03
Todd Vierling writes:
> On Tue, 27 Apr 1999, Alan Barrett wrote:
> : > > I would like to know the reason for this behavior. The behavior
> : > > can easily be fixed to conform to RFC, by sending "CWD /" just after
> : > > the ftp login (just give me a pointer...).
> : I didn't see the original message, so I am not sure exactly what problem
> : you encountered, but from the part that Perry quoted I believe that just
> : sending "CWD /" would be wrong.
> However, it's what all other Web-based FTP clients (see Lynx, Nutscrape) do,
> so we should match. Otherwise the URL ftp://host/path is NOT processed
> correctly, as we are *incorrectly* assuming that an FTP connection starts
> with cwd at /.
No, we are not *incorrectly* assuming that the CWD starts at `/'.
Read RFC 1738 section 3.2.2. This is documented in ftp(1), in the
section titled `AUTO-FETCHING FILES', under the description for
ftp follows RFC1738 with respect to ftp:// URLs. If you want an absolute
path, you must use ftp://host/%2fsome/absolute/path.
ftp used to send `CWD /' at the start of each transfer, and as perry
also pointed out, this confuses some ftp daemons. ftp also attempted
to cache connections if the host was the same, and use `CWD /' to get
back to the `top' each time. This also broke on some servers, and the
caching code was removed (which was no big deal, since it only could
have worked for host:path and not ftp://host/path auto-fetches).
If you read the man page for ftp, or the source, you would see that
this behaviour is documented to work like that for a reason...