Closed Bug 94354 Opened 23 years ago Closed 23 years ago

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

Categories

(Core Graveyard :: Networking: FTP, defect)

Product:
Core Graveyard
Component:
Networking: FTP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: Brade, Assigned: bbaetz)

References

(
URL
)

Details

(Keywords: testcase) 

In 4.x, if I go to this url (and enter my password):
ftp://userA@ic.net/./public_html/
it resolves and loads:  ftp://userA@ic.net/usr/guest/userA/public_html/

In 6.1, after I am prompted for a password, the url doesn't load.
-> dougt
Assignee: neeti → dougt
Component: Networking → Networking: FTP
What if you try to login with this url:

ftp://userA@ic.net/public_html/


that does not work; the dot is necessary

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

The logic of our ftp client is to:

login
cwd
cd 'url'
Whiteboard: need testcase
What does the "." mean?
Target Milestone: --- → mozilla1.0
qawanted - need to analyze the FTP session we attempt w/ a "."
Keywords: qawanted
reassigning to bbaetz@cs.mcgill.ca.
Assignee: dougt → 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.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.7
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.
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://userA@ic.net/./public_html/
 
ftp://userA@ic.net/./public_html/
ftp,userA,,ic.net,-1,/public_html/,,,,,,ftp://userA@ic.net/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.
benc: This is a dupe of bug 95277, I think. IF we did cwd ./foo instead of cwd
/foo, then it would Just Work.
bug 84242 has a patch attached to it that should solve this.
mozclassic has code to look for /./ in the url, and then remove the leading / in
that case, after sending PWD to update the directory.
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.
This should be fixed on the trunk with the checkin for bug 84242, marking fixed.
Reporter: Could you verify this is working fine now?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Sorry I haven't had a chance to verify this until now; this is now working.
Thanks!
Status: RESOLVED → VERIFIED
Keywords: qawanted → testcase
Whiteboard: need testcase
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.