231058 - Unusual URL when using "Up to higher level directory" in root directory of FTP server

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, defect)

Description

[olivier sannier]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

When using the link "Up to higher level directory" in the root of any FTP site,
then the URL that gets displayed adds ../ to the original one, but because the
server understands that it cannot go past beyond root, the content stays the
same. However, any "visited link" information is lost.

Reproducible: Always

Steps to Reproduce:
1. Go to ftp://ftp.mozilla.org/ for instance, any FTP will do
2. The URL displayed is ftp://ftp.mozilla.org/ and the content of the root is
shown. (only pub at the time of writing)
3. Click the "Up to higher level directory"
4. The content reloads, with only pub, but the URL displayed is
ftp://ftp.mozilla.org/../ where it should be ftp://ftp.mozilla.org/ because the
PWD command would have returned / if it was issued

Actual Results:  
Only the strange display, navigation is still possible

Expected Results:  
Like all FTP clients that I know of, issue a PWD command right after a CWD
command to check where you really are. This would allow not to display such a
weird URL and keep track of the visited links.

Comment 1

[olivier sannier]

Sorry, forgot to tell you that I also tried with my own web server and the
commands I receive are those ones:
syst
pwd
type I
pasv
size /
mdtm /
retr /
pasv
cwd /
list

Here, I click on "Up to higher level directory"

pasv
size /../
mdtm /../
retr /../
pasv
cwd /../
list

That's quite a lot of commands to get to list a directory, but anyway, I would
have expected a pwd just after the cwd /../ to check the current directory and
thus get the correct URL.

Comment 2

[Jesiah S]

I see what the reporter sees w/ LInux 200412608

Comment 3

[olivier sannier]

Attachment: Proposed patch to solve bug

This is only a proposition, it may not match requirements. It is believed to
work, but compilation wasn't tested.
Here is what it does:
Add a new member called mCWDBeforePWD to the nsFtpState class
When a CWD result is received (in R_cwd()), set mCWDBeforePWD and return
FTP_S_PWD instead of returning FTP_S_LIST
When a PWD result is received (in R_pwd()), if mCWDBeforePWD is not set, then
do the default behaviour (return FTP_S_TYPE). If mCWDBeforePWD is set, then
unsets it and returns FTP_S_LIST.

This way, the current working directory will always get updated with the value
returned by the server. Hopefuly, this will also mean that the history system
will pick up the correct informations as the URL hasn't changed.

Comment 4

[David Balažic]

I don't see a problem. 
You request mozilla to display ftp://ftp.mozilla.org/../ and mozilla does
exactly that. Thanks god ...

( because there are already enough problems(read: bugs) due to mozilla mangling
URLs instead of leaving them alone )

Comment 5

[olivier sannier]

It is a problem but not a show stopper. Why a problem ? Because /../ is not the
same as / when you are at the root of the server, but Mozilla displays them as
different and treats them as different with respect to the history.
As I said, every other FTP client does asks for the current directory to be sure
as to where the real directory is. The proposed fix does just that and it is not
too hard to include in the sources.

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[olivier sannier]

This is still a problem in the latest official Mozilla release.

Comment 8

[Jeff Walden [:Waldo]]

I'm not sure whether this is a bug to fix the file listings so that the "Up to" link isn't displayed at the top level of an FTP server or whether it's to make retrieving ftp://ftp.example.org/../ less work-intensive; if it's the former then this bug's a duplicate of bug 323056 (and not the other way around because there's a patch there), but if it's the latter then it's a separate bug.

Comment 9

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 10

[Patrick McManus [:mcmanus]]

no more ftp fixes except for critical issues