144717 - FTP client does not render UTF-8 filenames correctly

Status: VERIFIED DUPLICATE of bug 26767

(Core Graveyard :: Networking: FTP, defect)

Description

[Richard Jones]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412
Debian/0.9.9-6
BuildID:    20020412

I have an FTP server which is serving UTF-8 filenames. Mozilla does
not render these correctly: it appears to try to interpret them as
ISO-8859-1 characters, and the View -> Character Coding also says
ISO-8859-1.

The FTP server is Net::FTPServer which lists "UTF8" as a feature, as
shown below:

$ ftp localhost 5000
Connected to dev5.bibliotech.co.uk.
220 dev5.bibliotech.co.uk FTP server (Net::FTPServer/1.108-1 Schoolmaster FTP
Service) ready.
Name (localhost:rich): [...]
331 Username OK, please send password.
Password:
230-The server administrator has configured a welcome file,
230 but the file is missing.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote feat
211-Extensions supported:
 HOST
 LANG EN*
 MDTM
 MLST TYPE*;SIZE*;MODIFY*;PERM*;UNIX.MODE*;
 REST STREAM
 SIZE
 TVFS
 UTF8
211 END
ftp> 

RFC 2640 has some more information about using the FEAT
command and UTF-8 for pathnames:

http://www.zvon.org/tmRFC/RFC2640/Output/chapter3.html

Reproducible: Always
Steps to Reproduce:
1. Install Net::FTPServer or another FTP server which sends FEAT and UTF-8
pathnames.
2. Create a file or directory with UTF-8 name.
3. Attempt to view FTP page in Mozilla.

Actual Results:  Mozilla rendered the UTF-8 filename incorrectly, apparently
interpreting it as ISO-8859-1.

Expected Results:  Mozilla should have issued the FEAT command and used UTF-8 for
pathname transfer, as stated in RFC 2640.

Comment 1

[Richard Jones]

I have also tested this in Internet Explorer 6, and IE doesn't get this right
either.

However NCFTP running in a UTF-8 xterm displays the right thing.

Comment 2

[Bradley Baetz (:bbaetz)]

We don't support this. This is the first time I've seen a serrver which does,
though....

*** This bug has been marked as a duplicate of 26767 ***

Comment 3

[benc]

V