IE 8 Charset Bug

Earlier today I was playing around with a performance test case when I noticed that stylesheets and scripts were being requested twice in IE8.

IE8 Charset bug - Waterfall showing double HTTP requests

Eventually I figured out that the problem had to do with how the character set was specified. This is how things seem to work: In IE8, pages that rely on the META tag to define the character set — that is, pages that do NOT use the HTTP Content-type header to specify the character set — will request some stylesheets and scripts twice. Pages that indicate a character set via the HTTP Content-type header behave properly.

Test Page Using META Tag

On this page the character set is specified using only the META tag. The stylesheet and Javascript requests are sent twice. Notice that the initial requests do not receive a response.

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

IE8 Charset Bug - Resources requested twice

View test page

Test Page Using Content-type HTTP Header

On this page the character set is specified with the Content-type HTTP header. The stylesheet and Javascript are requested only once.

header('Content-type: text/html; charset=utf-8');

IE8 Charset Bug - Resources requested once

View test page

Other Test Pages

Interestingly, if you do not specify the character set at all, IE8 does not request the stylesheet and script twice. View test page.

If you use both the META tag and the Content-type HTTP header, the header will override the META tag and IE8 will only request the resources once. View test page.

Is it really a bug?

I was surprised to see that Googling this quirk did not turn up any results. My first thought was that the HTTP proxy was reporting false connections. But I was able to replicate the problem on HttpWatch, Charles, and Additionally, inspecting the server logs revealed the extra requests for the stylesheets (but curiously not the Javascript).

Then I thought it might have something to do with my webhost’s nginx and Apache configurations. But I tested some other sites at random and found the same problem with pages that did not specify the charset via HTTP header (two such pages: John Resig’s blog and

Billy Hoffman has a great post about charset and performance issues, in which he mentions that Firefox will re-request a URL if it detects a new charset after the initial URL request. That sounds like a very possible explanation for what is going on here: the initial stylesheet and script requests are sent, THEN the browser parses the META tag, forcing the stylesheet and script to be re-requested. But this seems odd considering the META tag occurs in the document before the stylesheet and script references.

Specifying the character set server-side instead of with the META tag is already considered a best practice, but if this IE8 behavior is accurate, the penalty for not adhering to the best practice is significant.

Update (5/16/2010)

In the comments Dave posted a link to this post by Eric Lawrence, which explains the bug and announces that it was (mostly) fixed in a 3/30/10 update. The post is worth reading, but I wanted to highlight the part where Eric recommends using the Content-type header to specify the character set:

However, the Update kills the bug in Scenario #1 by disabling the Lookahead Downloader when a restart is encountered. Hence, we continue to strongly recommend that web developers specify the CHARSET in the HTTP Content-Type response header, as this ensures that the performance benefit of the Lookahead Downloader is realized.

Both comments and pings are currently closed.


Thanks for the link! I updated the post with the new information. Windows says my system is up to date.. not sure how I missed that patch. :-?

I was getting the same ‘aborted’ error on IE while testing and I traced it back to charset meta tag. I solved it by adding an entry into .htacess. For now IE is playing nice, or that’s what its lead me to believe.

Also, I should mention here that my system is supposedly ‘all patched up’ as well. And yet for some reasons, Microsoft update forgot to apply this specific patch. So Rob you’re definately not alone, or crazy to miss such an important patch.