There is no reason in a modern web application for users to see a white error page

Sightings of the Twitter “fail whale” are, these days, fewer and far between. That’s a good thing. What’s interesting is that when it does show up, users are almost amused – as if they’re glad to see an old friend. I mean, come on; Twitter’s users named the whale, for crying out loud. How many of your users have a fan club for your error pages?

Exactly. That’s the kind of reaction you want from HTTP errors but what you usually get are surly, angst-filled, viral #fail messages that rapidly traverse the Interweb and make you look, well, like a throwback to 1994. There is absolutely no reason at all for users to see a page served from your site that contains any HTTP status code – good or bad. None. If you’re serving them up then you need to go directly to jail. Do not pass go. Do not collect $200.

This is especially important in environments in which server errors return additional information such as stack traces and other site-specific information that can provide the means by which miscreants can use and abuse your application to gain access or further corrupt content.

Even if you have thousands of servers, the core Apache or IIS/ASP.NET configuration files are likely duplicated – meaning you should be able to easily modify the original and push out the new one. Voila. Default error pages gone, hopefully happier users (or at least amused, if you’re lucky).

If your servers are deployed behind an application delivery controller or even the most rudimentary of load balancers these days, you can easily ensure the same thing with the same alacrity. A change in the configuration, a few lines of scripting, and your entire site will never show another HTTP status code to a user. The advantage to using the application delivery controller or load balancer is that no matter what the status of the server you can still deliver the page because the page can actually be constructed and stored on the device. That means if there’s a network issue or the server itself is completely unreachable that you aren’t delivering a white page to the user. Ever.

In the most extreme cases, an application delivery controller enabled with the right web acceleration solution can actually stand in for the server; that means it continues to deliver pages, albeit cached ones, until the site returns to normal.

Find something amusing or some entertaining way of apologizing to the users while being informative about the status of your application or site. Give them something to laugh (or at least chuckle) at when your site is having problems and instead of frustration accompanying the “X is down” messages flying across Facebook or Twitter or e-mail, you may find amusement and delight, instead.

Related blogs & articles:

• Your Stack Trace, Show It To Me
• DevCentral: Custom error pages by way of iRule
• Code Style: Custom error 500 internal server error
• ASP.NET Resources: ASP.NET Custom Error Pages
• Stop brute force listing of HTTP OPTIONS with network-side scripting
• Jedi Mind Tricks: HTTP Request Smuggling
• I am in your HTTP headers, attacking your application
• Understanding network-side scripting