I’ve previously mentioned one site that wasn’t working properly due to sending a malformed Content-Type header. Today, I encountered another site with a similar problem, but in a subtly different way. Looking at the IE9 F12 Network tab, you can see the problem:
As you can see, the Content-Type header is incorrectly formed. Instead of a semi-colon delimiting the type from the charset parameter, the site is using a comma. Instead of an equal sign delimiting the charset parameter name from the value (“UTF-8”), the site is using a colon.
What’s the result?
In the case of the stylesheet, its rules are not applied because the MIME type isn’t “text/css”, it’s the malformed string. The IE9 Developer Tools console notes:
Furthermore, even if the stylesheet had been applied, it would not have been interpreted with UTF-8 encoding, since the charset parameter was malformed. In the case of the JSON response, the same is true—the response would not be interpreted using the correct character encoding, as it was not properly specified. That could lead to security vulnerabilities in the application, depending on whether any part of the JSON was controlled by an untrusted party.
The proper values here are:
Content-Type: text/css; charset=UTF-8
Content-Type: application/json; charset=UTF-8
For the JSON response, it would also be a best practice to include an X-Content-Type-Options: nosniff directive to prevent the JSON from even potentially be interpreted as a different type of response.