Most users and developers are familiar with the standard HTTP error messages, particularly the infamous 404 and the almost-as-infamous, at least in web applications, 500, the dread Internal Server Error. Most web development environments let you override the standard web server error messages with your own versions, providing more (and less incongrous) information to the user. For any application, particularly when you make a conscious decision to present the error, this seems like a good idea. At the very minimum, it makes log analysis and error pinpointing that much easier.

The team desiging the Microsoft Exchange Web Access server gets this; but the IE folks don’t. This morning I tried to log in to an Exchange Web Mail environment for the first time. I did this in IE, and after entering my login information incorrectly I got a 403 (Unauthorized) error, which made sense. But after entering them properly I got a generic IE 500 error, indicating some internal crisis the system was not going to describe to me in any greater level of detail.

For some reason I decided to try it in Netscape (partially because I was curious whether the Exchange Web Mail function would even work with Netscape), and instead of the generic 500 got a message indicating that my account had been locked out and couldn’t be accessed. This made perfect sense, but all IE had done was blame Exchange for some internal collapse (and not set me on the way to resolving the problem).

It turns out I hadn’t disabled IE’s “Friendly Error Messages”, which replace whatever the server provides with a more helpful version. This is fine when the error message is an unhelpful server default, but when the application is using the messages as to provide information on valid modes of operation. Sure enough, once I turned this off (it’s on by default) I got the same message in IE as in Netscape.

So that’s today’s bit of web development wisdom: don’t override the standard error codes for your own application. Use regular (response 200) pages with error messages instead. It’s supposed to work, and you’re supposed to be able to do it, but all you’ll really manage is to confuse 80% of the browsing public. I’m actually not convinced that “Friendly Error Messages” are a bad idea, since most sites don’t provide enhanced error messages and the web server defaults aren’t generally that helpful for less technically inclined users. But that’s neither here nor there, since the going-forward assumption has to be that they’ll be there, and developers will have to work around them.

Anything else like this?