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:

image

The character encoding in use is named utf8, 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.

 

-Eric

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.