[Bug 23646] "us-ascii" should not be an alias for "windows-1252"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646

--- Comment #47 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Simon Pieters from comment #46)
> Examples of pages that break if us-ascii label doesn't encode as
> windows-1252 for URL query component or <form> submission:

Thank you! Can we now resolve this as WONTFIX, please?

(In reply to Henri Sivonen from comment #45)
> For example, the API should refuse to give you an encoder for "us-ascii" to
> force you to resolve the label "us-ascii" to windows-1252 first and then
> request and encoder for that. Once you've had to resolve the label to the
> encoding anyway, you should then use the canonical name of the encoding when
> labeling the outgoing data.

FWIW, as real-world existence proof of API of this nature, the Gecko-internal
API for obtaining a decoder and the Gecko-internal API for obtaining an encoder
take encodings--not labels. If a label is what you have, you have to to first
call a method that resolves a label into an encoding. (It's unfortunate,
though, that Gecko represents both encodings and labels as strings of 8-bit
code units instead of representing encodings either as an enumeration or aas
singleton objects inheriting from an abstract class. When properly designing a
new API, you should not use strings to represent encodings.)

The introduction of this API has already exposed a bug in SeaMonkey.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 5 August 2014 09:25:33 UTC