Google Chrome 2, CSS Content-Type and Amazon S3

It seems that ever since Google Chrome 2 was released, some of the CSS files I was serving from S3 were not being treated as valid by it, and the page layouts would break because of it. Firefox and IE were fine with it, and Chrome 1 was ok with it too. It was just Chrome 2.

A little inspection showed that the CSS files I stored on S3 were not being served with a Content-Type header, while from a standard apache web server they were. This combined with the new strictness of Chrome 2 (actually resulting from a new strictness in WebKit) made Chrome not treat these files as actual CSS, and break the page.

So the obvious solution was to make the CSS files be delivered from S3 with the correct “Content-Type: text/css” header. Fortunately enough, this is very easy to do with S3 API. Just pass the “Content-Type:text/css” header when you’re uploading the file to S3, and it will be present in the response headers whenever someone requests the file.

Here’s to the browser wars, that never end and got more complicated with the new player in town, Google Chrome.

Make Sure Those 404 and 500 Responses Are Long Enough

Internet Explorer is a term you can’t stay indifferent to. Whenever you hear somebody say it, they either say it with a respectful awe, or they utter it with a developer’s pain. Today I was on the latter side of this indifference, when I fought a WordPress bug.

Internet Explorer expects a minimum sized response content when receiving HTTP errors in the 400-500 area. If the content size received in the response is lower than this minimum, an arguably “Friendly HTTP Error Message” takes over, and displayed instead of the content.

This (rather obtrusive) behavior doesn’t go well with WordPress wp_die() function, which is invoked on many occasions throughout the WordPress code. This function sets the HTTP response status to 500, and then sends a very short html code containing any error message you’d like. These error messages are usually no more than a brief sentence, which results in a very small response content.

So take an IE7 browser, and try to post an empty comment on any WordPress that is not upgraded to version 2.7 yet. See that friendly browser message? The same in Firefox produces the expected “Error: please type a comment.” message. WordPress had already fixed this in 2.7 (you can copy their workaround) after some bug reports, but any installation prior to 2.7 which is still not upgraded (and many MU installations which always trail behind in the version releases) has this.

For any application other than WordPress, be sure to go over this table of minimum content size for each HTTP status error code, and make sure your responses are long enough.

Apparently, sometimes being laconic is bad.