54626 - ftp://user@host/some/absolute/path.txt does not work

Status: VERIFIED FIXED

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

Description

[Chris Waterson]

To reproduce, you must have a machine to which you have FTP login access (e.g.,
that you can "ftp" to non-anonymously):

1. Pick a file on the FTP server that you have access to; e.g., /tmp/foo.txt
2. Try to open the file directly using the "user@host" syntax; e.g.,

  ftp://waterson@btek/tmp/foo.txt

Expected: file opens
Actual: blank page. URL bar shows

 ftp:/waterson@btek/u/waterson/tmp/foo.txt

As you can see, it looks like we're dumping the user in his/her home directory
and not obeying the absolute path.

Comment 1

[Chris Waterson]

Repro on all platforms.

Comment 2

[Chris Waterson]

This is dogfood for me, because it means I can't get files onto the Mac without
using 4.x.

Comment 3

[Chris Waterson]

Hrm, not dogfood. I discovered I can get to a file using:

   ftp://user@host//tmp/foo.txt

Note the two slashes after the host name. This still seems wrong, and is
different from what 4.x did.

Comment 4

[Chris Waterson]

Ok, I take that back. The double-slash only gets me to the root directory. I
can't reliably pull files down with a double-slash in them. Dogfooding again.

Comment 5

[Gagan]

->rjc

Comment 6

[tenthumbs]

This is interesting. RFC1738 section 3.2.2 seems to be the place where
FTP URLs are defined. Here's a particularly useful paragraph:

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

Too bad Mozilla gets <ftp://luser@localhost/%2Ftmp/> wrong. Here's what
it did:
 
Sep 29 13:35:37 wu.ftpd[417]: connect from localhost
Sep 29 13:35:37 ftpd[417]: <--- 220 perfect FTP server (Version wu-2.6.0(1) Sat
Nov 27 18:51:10 CST 1999) ready.
Sep 29 13:35:37 ftpd[417]: command: USER luser^M 
Sep 29 13:35:37 ftpd[417]: <--- 331 Password required for luser.
Sep 29 13:35:49 ftpd[417]: command: PASS password^M 
Sep 29 13:35:49 ftpd[417]: <--- 230 User luser logged in.
Sep 29 13:35:49 ftpd[417]: FTP LOGIN FROM localhost [127.0.0.1], luser
Sep 29 13:35:49 ftpd[417]: command: SYST^M 
Sep 29 13:35:49 ftpd[417]: <--- 215 UNIX Type: L8
Sep 29 13:35:49 ftpd[417]: command: PWD^M 
Sep 29 13:35:49 ftpd[417]: <--- 257 "/home/luser" is current directory.
Sep 29 13:35:49 ftpd[417]: command: PASV^M 
Sep 29 13:35:49 ftpd[417]: PASV port 63251 assigned to localhost [127.0.0.1]
Sep 29 13:35:49 ftpd[417]: <--- 227 Entering Passive Mode (127,0,0,1,247,19)
Sep 29 13:35:49 ftpd[417]: command: TYPE I^M 
Sep 29 13:35:49 ftpd[417]: <--- 200 Type set to I.
Sep 29 13:35:49 ftpd[417]: command: SIZE /home/luser//tmp/c^M 
Sep 29 13:35:49 ftpd[417]: <--- 550 /home/luser//tmp/c: not a plain file.
Sep 29 13:35:49 ftpd[417]: command: MDTM /home/luser//tmp/c^M 
Sep 29 13:35:49 ftpd[417]: <--- 550 /home/luser//tmp/c: No such file or
directory.
Sep 29 13:35:49 ftpd[417]: command: CWD /home/luser//tmp/c^M 
Sep 29 13:35:49 ftpd[417]: <--- 550 /home/luser//tmp/c: No such file or
directory.
Sep 29 13:35:49 ftpd[417]: command: RETR /home/luser//tmp/c^M 
Sep 29 13:35:49 ftpd[417]: <--- 550 /home/luser//tmp/c: No such file or
directory.
Sep 29 13:36:06 ftpd[417]: <--- 221 You could at least say goodbye.
Sep 29 13:36:06 ftpd[417]: FTP session closed

Mozilla need to recognize an absolute pathname when it sees it.

Comment 7

[Robert John Churchill]

Attachment: First cut at a bandaid fix to get us back to 4.x compatability

Comment 8

[Robert John Churchill]

I just attached a quick fix to try and get us back to 4.x compatability.  Chris, 
care to try it out?

All of the following should then work as they did with 4.x:

ftp://user@machine
ftp://user@machine/tmp/foo.txt
ftp://user@machine/full-path-to-users-home-dir/file-in-users-home-dir

In regards to RFC1738 section 3.2.2, well... 4.x didn't follow the spec exactly 
either as far as I can tell.

Comment 9

[Robert John Churchill]

*** Bug 54287 has been marked as a duplicate of this bug. ***

Comment 10

[Robert John Churchill]

Attachment: Hmmm... last diff was bad; will this one be better?

Comment 11

[Chris Waterson]

Works like a champ for me.

Comment 12

[Robert John Churchill]

Adding "rtm" and updating status.

Comment 13

[Gagan]

r=gagan and adding rtm+

Comment 14

[Phil Peterson]

PDT marking [rtm++]

Comment 15

[Robert John Churchill]

Fixed on both branch and trunk.

Comment 16

[Robert John Churchill]

Re-opening due to orangeness.

Comment 17

[Robert John Churchill]

Attachment: Prevent orangeness...

Comment 18

[Robert John Churchill]

Fixed.

Comment 19

[Tom Everingham]

verified on branch
WinNT 2000100908
Linux 2000100909
Mac 2000100910

need to verify on trunk

Comment 20

[Rodney Velasco]

verified on trunk
oct 23 macos9
oct 25 rh7 linux
oct.25 winnt4.0
marking bug as verified and removing vtrunk keyword