All users were logged out of Bugzilla on October 13th, 2018

Status

()

P2
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: waterson, Assigned: mozilla)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fix in hand][rtm++])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Repro on all platforms.
Keywords: 4xp, correctness
OS: Mac System 8.5 → All
Hardware: Macintosh → All
(Reporter)

Comment 2

18 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

18 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

18 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

Comment 5

18 years ago
->rjc
Assignee: gagan → rjc

Comment 6

18 years ago
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

18 years ago
Created attachment 16005 [details] [diff] [review]
First cut at a bandaid fix to get us back to 4.x compatability
(Assignee)

Comment 8

18 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 9

18 years ago
*** Bug 54287 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

18 years ago
Created attachment 16016 [details] [diff] [review]
Hmmm... last diff was bad; will this one be better?
(Reporter)

Comment 11

18 years ago
Works like a champ for me.
(Assignee)

Comment 12

18 years ago
Adding "rtm" and updating status.
Keywords: rtm
Whiteboard: [fix in hand]

Comment 13

18 years ago
r=gagan and adding rtm+
Whiteboard: [fix in hand] → [fix in hand][rtm+]

Updated

18 years ago
Priority: P3 → P2

Comment 14

18 years ago
PDT marking [rtm++]
Whiteboard: [fix in hand][rtm+] → [fix in hand][rtm++]
(Assignee)

Comment 15

18 years ago
Fixed on both branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

18 years ago
Re-opening due to orangeness.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 17

18 years ago
Created attachment 16094 [details] [diff] [review]
Prevent orangeness...
(Assignee)

Comment 18

18 years ago
Fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 19

18 years ago
verified on branch
WinNT 2000100908
Linux 2000100909
Mac 2000100910

need to verify on trunk
Keywords: vtrunk

Comment 20

18 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

17 years ago
Component: Networking → Networking: FTP
You need to log in before you can comment on or make changes to this bug.