A few moments ago I was following a link from Google to Raymond Chen’s excellent MSDN blog The Old New Thing. As has happened to me before, I ended up getting redirected to an ASP.NET error page at a totally different URL, telling me that the site was “unable to service my request.”
Now, the inability to serve the requested page is fair enough; Raymond has previously mentioned that the
blogs.msdn.com site can be slow or overloaded because it comes under such relentless attack from comment spammers.
But a redirect to the absolute URL of an error page? That’s just annoying. It means that I can’t try to reload the page to see if the server has recovered from whatever issues are affecting it – or, more accurately, I can try to reload, but as I’m now at the absolute URL of the error page, I just keep reloading that.
Unsurprisingly, the HTTP 1.1 standard has already provided for this kind of situation by means of the
503 Service Unavailable status code:
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.
blogs.msdn.com people (who, by the way, Raymond is not responsible for) would use this status code to serve their error page for the post on Raymond’s blog, I could simply come back after a few minutes and try to reload the page, as my browser would still be at the same location.
It’s also possible that they do send this status code, but with a
Location: header to cause the redirect. (The server seems to be back on its feet again now, so I can’t inspect the HTTP cycle to check.)
Either way, what they do is wrong and broken. Don’t send people somewhere else to explain a
5xx Server Error status; simply serve the explanation directly using the appropriate 5xx status code, leaving your visitors ready to try a reload when the server has recovered. Otherwise, you’ll serve a lot of
200 OK responses from your error page, most of them to people who haven’t noticed that their location bar now points there as they hit
[Control | Command]-R in the hope of seeing what they originally came for.
Note: A more recent post examines this aspect of ASP.NET in greater depth, and suggests the use of a configuration option that resolves the problem.