61290 - FTP should try RETR before CWD

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect, P3)

Description

[D. J. Bernstein]

Typical FTP URLs don't say whether they are files, to be retrieved with
RETR, or directories, to be retrieved with CWD+LIST.

Mozilla tries CWD+LIST first; it will never try RETR if CWD succeeds.
Other browsers, including Netscape 4, try RETR first.

Mozilla's behavior creates two major problems. First, Mozilla is unable
to retrieve files from servers that accept all names as directory names,
because the CWD will always succeed. My combined FTP/HTTP server,
publicfile, works this way. According to the Netcraft survey, publicfile
is being used by more than 10000 *.com sites.

Second, Mozilla is unable to retrieve files from wuftpd, the Internet's
most common FTP server, when the files have names that match directory
names in wuftpd's cdpath. For example, if there's a file named /data,
and there's a directory named /users/data, and cdpath includes /users,
then Mozilla will misinterpret /data as /users/data.

The obvious fix is to do what everybody else does: USER+TYPE+PASV+RETR,
and then CWD+LIST if the RETR fails.

Comment 1

[Gagan]

->ftp

Comment 2

[G McAllister]

*** This bug has been confirmed by popular vote. ***

Comment 3

[matthewb]

What about the case when the path ends with "/" should cwd be done first in that
case?

Comment 4

[Gagan]

should be a plus for nsbeta1

Comment 5

[Doug Turner (:dougt)]

Fix checked in.  r=[e-mail]. sr=[e-mail]

Comment 6

[benc]

+testcase:
A file named "/data" should have the FTP URL escape encode the "/".

Comment 7

[benc]

My previous comment was not very relevant, I had been thinking about the URL
escaping test cases too much.

D.J.: I think I understand your point about wftp, but am still a bit unclear on
how to set it up:

have "/data" be a file. Have "/users/data" be a directory.

So what URL and what user account config would cause this to trip up?

Having the user's ftp home go to "/users" with a URL of <ftp://server/data/> ?

I think that problem was solved when the FTP parsing was changed so it broke RFC
1738 but fixed for the real world.