1387382 - HTTP header content-type text/plain; charset=cp437 ignored

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[azrdev]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170630112252

Steps to reproduce:

- Configure a server to return a text document encoded in CP437 with the header "Content-Type: text/plain; charset=cp437". example at <https://qrdn.de/dump/WXeEeqW6DHL/test.txt>
- open it with firefox


Actual results:

- it is shown in "quirks mode" with wrongly guessed charset windows-1252


Expected results:

- charset cp437 from header should be used

Comment 1

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

I didn't find any code in content viewer for plain text that uses the charset provided by HTTP response header. @bz may know more about how we handle the charset for plain text file.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Charsets aren't handled in content viewer anyway.  They're handled in StartDocumentLoad.

In this case, nsDocument::TryChannelCharset is called by nsHTMLDocument::StartDocumentLoad.  In TryChannelCharset, we see that the channel claims "cp437".  We call Encoding::ForLabel with that string and get back null, so we try other sources of charset information.

The real issue here is that we simply don't support cp437 and never have.  Furthermore, the encoding standard at https://encoding.spec.whatwg.org/#names-and-labels requires us not to support it: note the "User agents must not support any other encodings or labels" bits and the lack of "cp437" in the tables there.

I just checked, and Safari doesn't support this encoding either (shows "default").  Nor does Chrome (shows the file in the "macintosh" encoding for me).  Edge does support it, and IE has all along, but no one else ever has.  We shouldn't start now.

(I should note that this is the only bug report in the nearly 20 year history of this project to ask for cp437 support.)