Closed
Bug 54626
Opened 24 years ago
Closed 24 years ago
ftp://user@host/some/absolute/path.txt does not work
Categories
(Core Graveyard :: Networking: FTP, defect, P2)
Core Graveyard
Networking: FTP
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: waterson, Assigned: mozilla)
References
Details
(Whiteboard: [fix in hand][rtm++])
Attachments
(3 files)
61.98 KB,
patch
|
Details | Diff | Splinter Review | |
715 bytes,
patch
|
Details | Diff | Splinter Review | |
928 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Repro on all platforms.
Reporter | ||
Comment 2•24 years ago
|
||
This is dogfood for me, because it means I can't get files onto the Mac without using 4.x.
Keywords: dogfood
Reporter | ||
Comment 3•24 years ago
|
||
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.
Keywords: dogfood
Reporter | ||
Comment 4•24 years ago
|
||
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.
Keywords: dogfood
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://myname@host.dom/%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://myname@host.dom/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://myname@host.dom//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.
Assignee | ||
Comment 7•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
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.
Assignee | ||
Comment 10•24 years ago
|
||
Reporter | ||
Comment 11•24 years ago
|
||
Works like a champ for me.
Assignee | ||
Comment 12•24 years ago
|
||
Adding "rtm" and updating status.
Keywords: rtm
Whiteboard: [fix in hand]
Comment 14•24 years ago
|
||
PDT marking [rtm++]
Whiteboard: [fix in hand][rtm+] → [fix in hand][rtm++]
Assignee | ||
Comment 15•24 years ago
|
||
Fixed on both branch and trunk.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•24 years ago
|
||
Re-opening due to orangeness.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 17•24 years ago
|
||
Assignee | ||
Comment 18•24 years ago
|
||
Fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 19•24 years ago
|
||
verified on branch WinNT 2000100908 Linux 2000100909 Mac 2000100910 need to verify on trunk
Keywords: vtrunk
Comment 20•24 years ago
|
||
verified on trunk oct 23 macos9 oct 25 rh7 linux oct.25 winnt4.0 marking bug as verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Updated•3 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•