First posted to MSDN on Dec, 28 2010
If you want to master app compat debugging, then I really only know of one approach: practice. Find things that are broken, and then find out why. If you have to look too far for something broken, then you must be significantly luckier than I am!
Now, I prefer to listen to Mötley Crüe when I debug (or drive somewhere, or sit somewhere, or walk somewhere, or…), so it seemed only fitting that I would debug something for a member of Crüe while listening to Crüe.
Now, a while back, Nikki Sixx updated his
http://www.nikkisixx.net/
website. And, of course, the first thing I noticed is that it doesn’t render correctly on IE9 when in IE9 Standards mode. It renders fine, however, in IE8 or IE7 standards mode, and it also renders fine in Firefox, Chrome, Opera, and Safari. So, I figured it must be something with the new rendering engine, and went about with the assumption that our code was broken.
I first took a look with the developer tools, and spotted straight away the following error message in the Console tab:
SEC7113: CSS was ignored due to mime type mismatch
Interesting – so, perhaps it’s not a bug in IE9? I’m still a bit leery, because the fact that it works with every other engine seems to indicate something wrong with the one failing engine. So, I had a look with the new Network tab to see what I could find out about the MIME type. Here is what I found:
Content-Type text/css, charset: UTF-8
OK, so it is a CSS file, and it’s specifying a content type. So, I’m now perplexed as to what I am seeing. Of course, I’m not as conversant with the new developer tools, so I took a look with my old friend Fiddler just to make sure the headers are completely raw, and found this:
HTTP/1.1 200 OK
Server: Apache/2.2.11 (Fedora)
X-Powered-By: PHP/5.3.2
Last-Modified: Tue, 07 Dec 2010 19:19:31 GMT
ETag: 7d2160439e3d0b054b09b638c9516e70-gzip
Pragma:
Content-Length: 92090
Content-Type: text/css, charset: UTF-8
Cache-Control: max-age=600
Date: Tue, 28 Dec 2010 18:04:33 GMT
Connection: keep-alive
Vary: Accept-Encoding
Now, this all looks fine to my uneducated eye – it looks as if we are specifying a content-type, and it appears to me that it is the correct one. But that’s the key – I’m not completely conversant in the specifications! So, let’s learn the specifications…
If you take a look
here
, you can see precisely what you should have for the content type, and it’s in the format:
Content-Type := type "/" subtype *[";" parameter]
Wait a minute … the specification has a
semicolon
and the content had a
comma
– it looks like this web page is actually at fault, and every other rendering engine (including ours) was just being forgiving! Wow, IE9 appears to not be shouldering the blame here! (Though admittedly we are being a little picky, given that in the past we were letting that slide.)
Of course, just to make sure, let’s test things out. First I found the request and response in Fiddler. Then, on
www.nikkisixx.net/20621/global.css
, I chose to right-click, Save, Response, Entire response… and placed a copy of the response on my desktop. Then, I went in to the file, and replaced that comma with a semicolon. Finally, using the auto-responder from Fiddler, I fed this modified response to test out the fix.
Voila – when the header is modified to comply with specifications, it works! IE9 is vindicated, and I have a fix for the web page which involves a single character to make it compliant with standards. Now that the heavy lifting of debugging is finished, the only remaining challenge is to find the person who owns this page and point them to the fix, and then we can go
on with the show
.
Updated 29-December-2010
Daniel15 (
http://dan.cx
) points out correctly that I didn’t go quite far enough down that spec. While the semicolon instead of a comma is all it takes to get it working, it isn’t far enough to get it up to spec. Specifically, it shouldn’t be using a colon after charset. The spec indicates:
parameter := attribute "=" value
That should be an equal sign instead. So, to be more correct the header value should be:
Content-Type: text/css; charset=UTF-8
Thanks, Daniel! And, as John points out, this is a header, so the fix would be something configured on the server and not something the designer would have submitted.
