155223 - URL: Mozilla doesn't handle backslash in FTP username

Status: VERIFIED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[Aaron Kaluszka]

From bug 124561
------- Additional Comment #39 From Dave Roeser  2002-07-01 11:03 -------

If I have encountered a new problem or picked the wrong one to update I
apologize. We have a large customer who currently uses NN 4.79 for all their
work including FTP. They did a test of Nav 6.2.3 this past weekend and FTP
failed (at least to get to our site). Our customers are not allowed to use
"anonymous" (don't know why except we use m$ windoze everywhere - unfortunatly).
The following works for NN 4.79 (and you are free to test as much as you wish)

ftp://mainstar.com\customer:[e-mail]

The user is "customer" and the password is "4ms390use"

In NAV 6.2.3 and Mozilla 1.0 Build 2002053012 we receive an ALERT box
with "530 user anonymous cannot login" 
I tried with and without the password, with and without the backslash separating
the domain and userid. We did show the user they could use DOS command line
(worked well) or any number of FTP clients. The following also did not work
ftp://ftp.mainstar.com
interestingly enough the above command in Opera brought up a dialog box for
username and password.
Thanks.

---

Note that escaping the backslash makes the request work.
ftp://mainstar.com%5Ccustomer:[e-mail]

Comment 1

[benc]

Is is possible the "\" is some kind of delimiter that affects the parsing of the
hostname?

Comment 2

[Andreas Otte]

On windows there still is this ugly fixup code in docshell that changes \ to /.
The link works fine from linux. Another nail in the coffin of this windows only
fixup stuff. 

Comment 3

[benc]

Well this URL doens't do what it intended anyhow, so if they use the correct
URL, the windows-only fixup code does have some utility...

What I really don't undrstand is how the escaped version works w/ the remote
server, isn't the username:

mainstar.com%5Ccustomer ?

Comment 4

[Andreas Otte]

What happens here is that with the windows fixup code

ftp://mainstar.com\customer:[e-mail]

becomes

ftp://mainstar.com/customer:[e-mail]

so we get an ftp url with no username/password, a host named mainstar.com and a
file customer:[e-mail] to get

With

ftp://mainstar.com%5Ccustomer:[e-mail]

the urlparser uses mainstar.com%5Ccustomer (unescaped) as user, 4ms390use as
password and ftp.mainstar.com as host as it should be.

With mozilla and no username we always assume anonymous login, with 
ftp://mainstar.com\[e-mail] you will see the username/password
box (on linux, use %5C on windows). Maybe we should present the user the
username/password box when anonymous login is not allowed instead of showing the
alter box.

Comment 5

[Dave Roeser]

I am not sure what #3 meant by 
"Well this URL doens't do what it intended anyhow, so if they use the correct
URL, the windows-only fixup code does have some utility..."

It is working as intended. Our customers can FTP output, system dumps, etc so
the developers can see what is going on and we post fixes in the various
sub-directories (there is one for each product). The customer in question passes
along their "thanks" especially for knowing about the escaped backslash. They
will use the "workaround" during the rest of their testing. As I understand it,
the mainstar sysadmins shut off user "anonymous" because they could not find a
way to protect themselves.

Comment 6

[Bradley Baetz (:bbaetz)]

Instead of using \, try using %5C.

-> networking, this is a gneric uri fixup bug.

Comment 7

[benc]

What I meant was: is example is not a reason to get rid of the windows-only URI
fixup code (which comes up for dicussion every release or so...)

Comment 8

[Andreas Otte]

I think is a very good reason, nothing demonstrates it better. At least it is a
reason to make it better. Why does it go after a \ in the password when \ is
clearly only a *path* delimiter on windows?
Okay, its a Dog-Tail problem, unless we parse the url we do not know what the
path is and in order to know that we might have to move a \ to a /, which we
should not do unless we are sure we are doing the right thing.  :(


 

Comment 9

[benc]

andreas: I've been meaning to ask, is this fixup code only in URL bar, or in Necko?

Comment 10

[Andreas Otte]

Any fixup code that converts \ to / was removed from necko a long time ago. All
is left is in the docshell which usually gets called from the urlbar. However I
remember at least one case where a link in a page triggered the fixup through
docshell, maybe when the link opens a new window.

Comment 11

[benc]

-> URL bar.
Makes sense. I tried URL bar via windows, and it failed. I clicked on the link,
and it works. Netscape 7.0, Win98.

Comment 12

[Doug Turner (:dougt)]

wfm 1.2b windows.  something must have change.  reporter, please verify. :-)

Comment 13

[Aaron Kaluszka]

Works now, I think this may have been fixed by another bug, but I don't remember
the number.

Comment 14

[Dave Roeser]

Thanks. I just tested in 1.2b Build 2002101612 and it works. I am still new to
bugzilla so as the reporter of this do I need to flag any fields that mark ready
to close?