IE9 Compatibility: Proper Use of the Charset Token

Recently, during site-compatibility testing of IE9, we encountered a cool online game that does not load properly in Internet Explorer. Using the F12 Developer Tools’ Script debugger, the page immediately hits a script error (“c00ce56e”) while loading:

F12 Showing Script error

A quick search on this error code turns up a Microsoft KB article  explaining that this error code is shown when the server specifies an unsupported character encoding for the response. The KB article points out that “ISO8859_1” is not a proper alias for a supported character encoding named “ISO-8859-1”.

Looking at the game’s traffic in Fiddler, the problem is immediately apparent:


The character encoding in use is named utf-8, and utf8 (without the dash) is not a supported alias for this character encoding. Hence, when this page attempts to load its JSON content, a script error is encountered because the character encoding is not recognized.

I quickly whipped up a tiny bit of FiddlerScript to verify my theory:

static function OnPeekAtResponseHeaders(oSession: Session) {
    // Fix up malformed Character Set       
    if (oSession.oResponse.headers.ExistsAndContains("Content-Type", "utf8"))
        oSession.oResponse.headers["Content-Type"] =
            oSession.oResponse.headers["Content-Type"].Replace("utf8", "utf-8");
        oSession["ui-backcolor"] = "green";

This script will replace any instances of utf8 with the proper utf-8. I cleared my browser cache and reloaded the game, and it now works properly!

Specification of the a HTTP response’s encoding using the Content-Type HTTP header is a best practice for both performance and security reasons. Generally speaking, UTF-8 is a great choice. However, it’s important to specify the correct encoding value, using the correct encoding name. Attempting to accommodate improperly specified encodings can lead to compatibility, interoperability, and security problems.



Comments (5)
  1. Daniel says:

    Out of curiosity, what do other browsers do? Wouldn't the general principle of "be liberal in what you accept" dictate that clearly unambiguous spellings should be permitted?

  2. EricLaw [MSFT] says:

    @Daniel: As I mentioned, being "liberal" can lead to severe security bugs, unless there's complete agreement (aka a standard) on what the expected "liberal" behavior is. Otherwise, one piece of code might say: "Oh, no possibility of script injection here in this string in Encoding#1" while another piece of code would say: "Oh, this isn't really Encoding#1, it's Encoding#2… Let's run that script we've found." Bang.

  3. EricLaw [MSFT] says:

    If you're wondering, yes, we did reach out to the site owner, and we've been playing an alpha build where they've fixed this problem. 🙂

  4. ErikF says:

    Obviously you'll need to test the new site for compatibility issues; how much other work are you getting done? 🙂 (My top score is a disappointing 120…)

  5. EricLaw [MSFT] says:

    🙂 I don't think I've gotten a score higher than about 20, but we have a developer on the team who loves this game.

Comments are closed.

Skip to main content