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

RESOLVED WONTFIX

Status

()

Core
Networking: FTP
--
minor
RESOLVED WONTFIX
15 years ago
3 years ago

People

(Reporter: olivier sannier, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

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

15 years ago
I see what the reporter sees w/ LInux 200412608
OS: Windows XP → All
(Reporter)

Comment 3

15 years ago
Created attachment 140045 [details] [diff] [review]
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

14 years ago
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 )
(Reporter)

Comment 5

14 years ago
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.
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/
(Reporter)

Comment 7

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

Comment 8

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

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
no more ftp fixes except for critical issues
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.