If you’re a web developer and you’re worth your salt, you know about HTTP message headers and status codes. More importantly, you know that if your web app or web server runs into problems, the response it sends to the browser should use an HTTP error code like “404 Not Found” or, my personal favorite, “500 Internal Server Error”.
Now, it’s relatively common for web applications and servers to not send any HTML back to the browser along with the error code; in this scenario, almost all web browsers will just display their own, generic error message (hopefully) explaining what the error code means. But if you happen to be the kind of eager-beaver developer who wants a spiffy, custom error page to be displayed instead of the generic one offered by the browser, or if you’re just an innocent WordPress user, pay attention.
IE and the Amazing 512-byte Threshold
As it turns out, Internet Explorer (prior to version 7) will ignore your custom error page if it’s too small (e.g., fewer than 512 bytes) and always display its own, Microsoft-stylin’ error page instead. As a matter of fact, there are a series of Internet Explorer “error threshold” settings in the Windows system registry which specifically dictate how big, in bytes, an HTTP message body must be for it to be displayed for specific HTTP error status codes (Jeff Starr has written an excellent blog post summarizing the error codes and corresponding thresholds). The largest threshold is 512 bytes, which means that if you want to use HTTP error codes with custom pages, you need to ensure that the text that makes up your page amounts to more than 512 bytes. And if you’re a smarty-pants performance nerd using gzip compression to shrink the size of the HTTP message body (i.e., so that it can be downloaded by the browser faster), note that your error page HTML needs to be bigger than 512 bytes after the compression.
If it’s not already clear, I should point out that I cannot take credit for figuring out this crazy 512-byte thing. As far as I know, however, I can take credit for figuring out that this is why the de-facto WordPress 2.7 error page isn’t displayed on Internet Explorer, assuming you’re using gzip compression, a bug which I have reported to the WordPress folks.
Example: WordPress “Post Comments” Error Page
To help understand the problem, let’s take a look at an example: the “user comment” feature in WordPress 2.7 (which, if enabled, allows people to add comments to WordPress posts). You can configure WordPress to require that the user enter a name and email address before accepting the comment, or if your’e using a plugin like SI CAPTCHA, they must additionally look at an image and type in the text that they see to prove that they’re an actual person and not spam software. If the form validation fails, WordPress produces an error page with a “please fill in the required fields” message and sends it to the browser using the “500 Internal Server Error” HTTP status code. If you’ve got gzip compression turned on, the raw HTTP message sent to the browser looks like this:
First, you can see that gzip compression is being used, as indicated by both the “Content-Encoding” header and the obviously garbled message body data. More importantly, the “Content-Length” header indicates that the HTTP message body is 386 bytes–clearly under the 512-byte limit required by Internet Explorer. This results in IE displaying the following generic error page:
The Solution: “Ve Vant to Pump…You Up!”
One obvious solution to the problem is to put enough text so as to ensure that it’s larger than 512 bytes, even after gzip compression. In this specific example, the error page HTML generated by WordPress is defined in the wp_die() function of the wp-includes/functions.php file. Although it is probably not the most elegant solution, I fixed the problem by using the PHP str_repeat() function to generate 80,000 periods inside an HTML comment:
It’s worth noting that the WordPress developers were apparently aware of IE’s 512-byte threshold problem; on line 2,293 they use the same str_repeat() function to insert enough spaces so as to ensure that the HTML contains a total 512 8-bit characters (and therefore amounts to 512 bytes). The problem is that if you’re using gzip compression, those 512 bytes are easily shrunk into less than 400 bytes. After some trial and error, I found that generating 80,000 periods results in an HTTP message body totalling 519 bytes after compression:
Now that the error page is larger than 512 bytes, Internet Explorer displays it correctly:
So, while several people have been aware of Internet Explorer’s bizarre, 512-byte error page behavior for a few years, this specific WordPress bug seems to be undocumented. My intent in writing this post is to hopefully provide a useful Google search result for another poor soul who is desperately trying to figure out why their WordPress 2.7 comment validation error messages aren’t being displayed to Internet Explorer 5/6 users. The temporary fix that I’ve proposed (modifying the wp_die() function in functions.php) will hopefully be replaced by a proper solution in the next release of WordPress; keep an eye on WordPress bug #8942.