94354 - url with a login and '.' in path does not resolve properly

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Kathleen :Brade]

In 4.x, if I go to this url (and enter my password):
ftp://[e-mail]/./public_html/
it resolves and loads:  ftp://[e-mail]/usr/guest/userA/public_html/

In 6.1, after I am prompted for a password, the url doesn't load.

Comment 1

[John Taylor]

-> dougt

Comment 2

[Doug Turner (:dougt)]

What if you try to login with this url:

ftp://[e-mail]/public_html/

Comment 3

[Kathleen :Brade]

that does not work; the dot is necessary

Comment 4

[Doug Turner (:dougt)]

benc, can you help us get some kind of test case?

The logic of our ftp client is to:

login
cwd
cd 'url'

Comment 5

[benc]

What does the "." mean?

Comment 6

[benc]

qawanted - need to analyze the FTP session we attempt w/ a "."

Comment 7

[Doug Turner (:dougt)]

reassigning to [e-mail].

Comment 8

[Bradley Baetz (:bbaetz)]

ftp://host should log into the users home directory, but it doesn't do so at
present.

The . probably tricked 4.x into going to the home directory, I guess. We're
probably doing CWD /./public_html/

I know this used to work, but neither dougt or I can find the code which did
so...

I'll look into this.

Comment 9

[benc]

RFC 1630 suggests that "/./" would never occur in a canonical URL b/c:

"
      Within the result, all occurrences of "xxx/../" or "/." are
      recursively removed, where xxx, ".." and "." are complete path
      elements.
"

I haven't worked through the more recent RFC's, so I've cc:andreas for his 
advice.

Comment 10

[Andreas Otte]

We currently normalize the url according to the rules in rfc 1630 and for
example 2396. However these rules apply to relative urls. On the other hand .
and .. are part of the syntax that describes the url hierarchy (as well as /)
and what we do is well within the rules.

urltest ftp://[e-mail]/./public_html/
 
ftp://[e-mail]/./public_html/
ftp,userA,,ic.net,-1,/public_html/,,,,,,ftp://[e-mail]/public_html/

I think this also boils down to the way we are handling the first / in ftp urls.
Loging into the users home directory and ignoring the first / we would do the
right thing here. No need for a dot.

Comment 11

[Bradley Baetz (:bbaetz)]

benc: This is a dupe of bug 95277, I think. IF we did cwd ./foo instead of cwd
/foo, then it would Just Work.

Comment 12

[Andreas Otte]

bug 84242 has a patch attached to it that should solve this.

Comment 13

[Bradley Baetz (:bbaetz)]

mozclassic has code to look for /./ in the url, and then remove the leading / in
that case, after sending PWD to update the directory.

Comment 14

[Andreas Otte]

No need for that code with the latest patch from bug 84242. That trick was
necessary because 4.x was just doing the wrong thing with normal ftp urls.

Comment 15

[Andreas Otte]

This should be fixed on the trunk with the checkin for bug 84242, marking fixed.
Reporter: Could you verify this is working fine now?

Comment 16

[Kathleen :Brade]

Sorry I haven't had a chance to verify this until now; this is now working.
Thanks!