Closed Bug 1387382 Opened 3 years ago Closed 3 years ago
HTTP header content-type text/plain; charset=cp437 ignored
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
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.
Component: Networking: HTTP → DOM
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.)
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.