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://' URLs.

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...