Unfortunate 500

But still, your site will be generating script errors. It might be your shopping cart, your contact forms, or your database interface routines, but someone, somewhere, is almost certainly seeing server script errors. There are particular triggers that will generate these errors and, in our experience, some of the most common are:

Unfortunate 500

Visitors with computers set to use non-Western languages, especially if they are using double-byte character sets. These might break your validation routines, database interface scripts, or file system interaction.

Visits from search-engine robots. Googlebot might come and grab ancient files that no longer work, or it might access a file without the query string or form data that you would assumed would always be present.

Users always seem to have problems with dates in forms. Despite your including clear ‘dd/mm/yyyy’ instructions, someone will still want to type in ‘circa 1994’.

Likewise with numeric values: if you have a ‘maximum price’ field in a search form, someone will type in something like ‘£400,000+’, which is not of much use if your code is expecting a purely numeric value.

Of course, none of these events should cause a problem, as the code that drives your sites really ought to be written to cope with things such as this; also, your site testing should have picked up these types of errors. Meanwhile, back in the real world, since all our sites display these kinds of errors, how do you go about finding and fixing them? Simple enough:get the server to alert you whenever they happen. Remember how we showed you how to set up your server so that you get an email whenever a 404 error occurs? Well, to find these server-side scripting errors, you need to do something vaguely similar. Such errors are usually referred to as ‘500 errors’ after their HTTP status code: much the same way a ‘file not found’ generates a 404 code, server errors will always generate a 500 code.

Let’s examine what is required and how to set it up. We will show you the process for Microsoft’s IIS web server and, before anyone accuses us of showing some kind of Seattle-directed bias here, the reason we have selected IIS is because, in our experience, it is the web server that tends to host the majority of script errors. However, you shouldn’t find it too difficult to adapt what we have shown below to work with other web servers.

First of all, you need to tell the web server that any 500 errors need special handling. If you open up the IIS management console and take a look at the properties for one of your websites, you will see that there is a Custom Errors tab. Scroll down this list to find 500;100, which is the error that gets raised by a server-side scripting error. (You can see a full list of the other 500 codes generated by IIS at support.microsoft.com/?id=318380).

Change the entry for 500;100 so that it becomes a URL type with a content of something like /500handler.asp. Our thanks to reader Dave Walsh from Brighton for the original inspiration behind the code that now follows. Within the 500handler.asp script, the main chunk of code will look something like this. First, grab a couple of server variables that might come in useful:

agent = Request.ServerVariables(“HTTP_USER_AGENT”)

ref = Request.ServerVariables(“HTTP_REFERER”)

And if you are working on something like an intranet, then maybe you will find the user’s name and email stored in session variables:

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.

Todays Highlights
How to See Google Search History
how to download photos from google photos