This blog is closed as of 2/2015. @EricLaw left Microsoft in 2012, but was named an IE MVP in '13 & an IE userAgent ( in '14.

IE9 Compatibility: Proper Use of the Charset Token

IE9 Compatibility: Proper Use of the Charset Token

  • Comments 5

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.



  • 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?

  • @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.

  • 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. :-)

  • 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...)

  • :-) 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.

Page 1 of 1 (5 items)