271923 - "550 ...: No such file or directory" when using FTP

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, defect)

Description

[Stephen Rasku]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

When I try to download a file using Mozilla:

	ftp://10.1.1.31/pub/per-results-1-20041126-110336.csv

I get:
	
550 /home/ftp/pub/per-results-1-20041126-110336.cvs: No such file or directory.

Using the same URL in IE 6.0 works fine.

Reproducible: Always
Steps to Reproduce:
1. Enter FTP URL in address bar
	/home/ftp/pub/per-results-1-20041126-110336.cvs
Actual Results:  
550 /home/ftp/pub/per-results-1-20041126-110336.cvs: No such file or directory.

Expected Results:  
The file should have been downloaded.

This is connecting to a FTP server on QNX 6.2.1b.  I am reporting this as
occuring in Windows XP but I also saw this problem with the 0.9.8 client for
QNX.  I suspect all OSes have this problem.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

does it work if you use:
  ftp://10.1.1.31//pub/per-results-1-20041126-110336.csv

(note the second slash)?

Comment 2

[Stephen Rasku]

Yes.  But why?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

well, the way mozilla's ftp code currently works is: if you use a single slash,
then the path is interpreted relative to the initial directory on the ftp
server. if you use two slashes, the path is relative to the root directory on
the server.

note: don't know whether that's a bug or a feature :-)

Comment 4

[Andreas Otte]

As far as I remember it is a compromise between the specs (rfc1738) and what is
happening on the net. 

EXCERPT:

For example, the URL <URL:ftp://[e-mail]/%2Fetc/motd> is
interpreted by FTP-ing to "host.dom", logging in as "myname"
(prompting for a password if it is asked for), and then executing
"CWD /etc" and then "RETR motd". This has a different meaning from
<URL:ftp://[e-mail]/etc/motd> which would "CWD etc" and then
"RETR motd"; the initial "CWD" might be executed relative to the
default directory for "myname". On the other hand,
<URL:ftp://[e-mail]//etc/motd>, would "CWD " with a null
argument, then "CWD etc", and then "RETR motd".

mozilla differs from the spec because it interprets // and %2F/ the same for
ftp. This is the compromise, because using %2F seems to burdensome. On the other
hand IE is totally doing the wrong thing because it does not interpret the given
url as relative to the home of the login-user (as it should by rfc1738).

Using // the way mozilla does now seemed to be a good compromise (not to
damaging to the spec because // in the spec ist totally redundand with /) and I
still stand by it.

The download-url should be fixed to use %2F/ (more to the spec) or // to access
the file. IE should be able to handle it too, but IE seems not to be able to
access files relative to the login-users home.

Comment 5

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 6

[Patrick McManus [:mcmanus]]

only critical ftp fixes now