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

 

-Eric