Why Won’t Internet Explorer Display Your WordPress Error Page (Or Any Custom HTTP Error Page, For That Matter)? Because It’s Too Small.

by Clint on January 23, 2009

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

[ad]

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:

This screenshot shows the raw HTTP message generated by WordPress after the comment form submission failed validation.

This screenshot shows the raw HTTP message generated by WordPress after the comment form submission failed validation. Note that size is 386 bytes. The free OS X packet-sniffing program called Eavesdrop was used to capture the exchange.

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:

Screenshot showing the standard "500 Internal Server Error" page which is displayed by Internet Explorer when a custom error page is less than 512 bytes.

Screenshot showing the standard "500 Internal Server Error" page which is displayed by Internet Explorer when a custom error page is less than 512 bytes.

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:

This screenshot shows how the wp_die() function was modified to ensure that the WordPress error page was larger than 512 bytes, even after gzip compression. The custom code begins on line 2294.

This screenshot shows how the wp_die() function was modified to ensure that the WordPress error page was larger than 512 bytes, even after gzip compression. The custom code begins on line 2294 and involves using the str_repeat() function to generate an additional 80,000 characters in the error page HTML.

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:

This screenshot shows that the size of the WordPress error page was increased to 519 bytes (after compression) after modifying wp_die() to generate an additional 80,000 characters in the resulting HTML.

This screenshot shows that the size of the WordPress error page was increased to 519 bytes (after compression) after modifying wp_die() to generate an additional 80,000 characters in the resulting HTML.

Now that the error page is larger than 512 bytes, Internet Explorer displays it correctly:

This screenshot shows that Internet Explorer correctly displays the WordPress "500" error page after the size was increased to 519 bytes.

This screenshot shows that Internet Explorer correctly displays the WordPress "500" error page after the size was increased to 519 bytes.

Summary

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.

Clint Harris is an independent software consultant living in Brooklyn, New York. He can be contacted directly at ten.sirrahtnilc@tnilc.
  • iZ

    thank you for this!really helpful

  • Jay

    Hey! Great blog. I’m not a techie or developer so this was a little over my head. The problem my blog is experiencing comes when people try to leave comments. When they submit a comment, the next page appears with the following message:
    500 – Internal server error.
    There is a problem with the resource you are looking for, and it cannot be displayed.

    However, I do receive their comments.

    I’m not sure what browser others are using, but I experienced it as well using Firefox. I also experience that error message when I attempt to log out of my wordpress account from the comment area.

    I would appreciate any help you could provide. Thanks in advance.

  • http://www.clintharris.net Clint

    Hey Jay, thanks for the positive feedback on the blog. As far as your question goes, unfortunately it doesn’t sound like the same issue I was having (i.e., the 512-byte thing described in the post). In my case, the problem only occurred with IE; if you’re getting a “500″ error after submitting comments when using Firefox, there’s probably something else going on. Have you tried posting to the WordPress support forums?

  • http://www.kimflournoy.com Kim Flournoy

    Thanks! This one had me baffled, and I was worried that I’d need to start troubleshooting my Apache configuration or something, since it just didn’t make sense. After all these years, I can’t believe I’m still adding new items to the “Why IE6 Sucks” list…

  • http://www.semiologic.com Denis

    Someone who experienced this bug, please be so kind to go into trac, and check if things are fixed with the candidate patch. It needs some testing.

  • http://www.clintharris.net Clint

    @Denis: I just tested the patch and it seems to work fine.

  • Pingback: Wordpress 2.6 / 2.7 comment error 500 » Rax

  • Anonymous

    This is great. I so much love the way you wrote it. Very interesting and informative. Keep posting Clint!

  • http://twitter.com/mani313 Manikandan

    I face bulky error in IE all versions that the pages are not shown exactly…there is only error in page block. when open the page url header,footer shown fine but in page block there are two blocks are shown instead of one. both are holds blank no title and content….can any one help me out where error was been….r…how do i fix this?

  • artsology

    Is there a way to customize the WordPress “500″ error page so that it looks like the rest of my site?

  • PJHH

    So let me get this straight. In order to guarantee that your page, after gzipping, is > 0.5KB, you add 80KB (empirically determined, of course) of highly compressible data? Rather than, say 2-3KB of random data.

    Makes so much sense… o_O.

    And you consult on software you say?