http-index-format directory listings should send 301: encoding line




7 years ago
a year ago


(Reporter: info, Unassigned)


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-would-take])



7 years ago
Numerous bugs have been filed about character encodings in directory listings (ftp, jar, etc.).  It seems many of these have been "fixed" by allowing the user to change View > Character Encoding, change intl.charset.default, or relying on auto-detect.

But in those cases where Mozilla knows the encoding of the directory listing, it should specify it and avoid any problems. Mozilla produces directory listings using a textual http-index-format ( , and then transforms this into HTML. This format includes a
  301: <encoding>
line, see , but it is undocumented and seems unused.

One test and proof of this is to connect to an FTP server and browse a directory full of files with special glyphs in their names. They appear wrong if you leave your intl.charset.default at the default of ISO-8859-1, because all FTP servers are supposed to issue UTF-8 directory listings, but Mozilla's http-index-format representation of the FTP doesn't tell itself to use UTF-8, and it all gets garbled.

You can see garbled characters at (bug 26767).

I captured some http-index-format output, added the 301 charset line, and configured my server to serve this.  Compare
with the added 301 line:

Similarly, compare browsing the contents of the jar file
with the added 301 line:
(The ?x query string on these URLs avoids bug 367076 where http-index-format adds a / and becomes a 404 when you view source, reload, or change character encoding.)

Adding a "301: UTF-8" line fixes accented characters in listings, but Asian glyphs seem to remain problematic.  Maybe this can be part of the solution to bug 26767, bug 502540 and others.


7 years ago
Blocks: 502540
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.