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:

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:
username = session(“fullname”)

useremail = session(“email”)

It is also worth adding in any other variables that you think might be useful. Next, use the GetLastError method of the Server object:

set objErrorInfo = Server.GetLastError

And now you start building up a message with details of the error:

msg = “There has been a script error on the website “&vbCrLf

You can add the name and email fields if they were present:

if username “” then

msg = msg & “Users Name = “&username &vbCrLf

end if

if useremail “” then

msg = msg & “Users email = “&useremail &vbCrLf

end if

And now you can start to add in details of the error itself, which are all grabbed from that GetLastError object:

msg = msg &”ASPCode = ” & objErrorInfo.ASPCode &vbCrLf

msg = msg &”ASPDescription = ” & objErrorInfo.ASPDescription &vbCrLf

msg = msg &”Category = ” & objErrorInfo.Category &vbCrLf

msg = msg &”ASPCode = ” & objErrorInfo.ASPCode &vbCrLf

msg = msg &”Description = ” & objErrorInfo.Description &vbCrLf

msg = msg &”File = ” & objErrorInfo.File &vbCrLf

msg = msg &”Line = ” & objErrorInfo.Line &vbCrLf

msg = msg &”Number = ” & objErrorInfo.Number &vbCrLf

msg = msg &”Source = ” & objErrorInfo.Source &vbCrLf

set objErrorInfo = nothing

That’s all the info that you can grab from Microsoft’s ErrorInfo object, but there are other things that might be of interest when a page bombs out. First, you can add in the user agent and referrer variables you saved earlier:

msg = msg &”Referrer = ” & ref &vbCrLf

msg = msg &”User Agent = ” & agent &vbCrLf

Second, it might be useful to know the query string that was used when the page was being accessed:

msg = msg &”Qstring = ” & Request.ServerVariables(“query_string”)&vbCrLf

And were any form fields being POSTed to the page?

msg = msg & “POST Form fields:” &vbCrLf

For Each key in Request.form

msg = msg & ” ” &key&” – “& Request.form(key) &vbCrLf

next

There is always the chance that the error was triggered by a stray cookie, so why not add those into the message as well:

msg = msg & “Cookies:” &vbCrLf

For Each cookie In Request.cookies

If Request.cookies(cookie).HasKeys Then

For Each key In Request.cookies(cookie)

msg = msg &cookie&”(“&key&”)=”&Request.cookies(cookie)(Key)&vbCrLf

Next

Else

msg = msg & cookie”=”&Request.cookies(cookie)&vbCrLf

End If

Next

And then finally, chuck in the complete set of server variables:

msg = msg & “Server Variables:” &vbCrLf

For Each key in Request.ServerVariables

msg = msg & “info ” & key

if Request.ServerVariables(key) = “” then

msg = msg & ” – empty” & vbCrLf

else

msg = msg & ” – “&Request.ServerVariables(key)& vbCrLf

end if

Next

The error message is now complete and it could be used as the body of an email, saved in an error log or even sent via something like ICQ or MSN Messenger. Even better, do all of these at once. This technique will alert you to things such as coding errors, problems with include files, database/SQL syntax problems, script execution time-outs, and much more. We seriously encourage you to add this code, or something like it, to all of your scripted sites, and you will be surprised at the bugs you will find – often bugs that have been lurking there for ages. Even high-profile websites aren’t immune.

Securing IIS

One of the questions that crops up from time to time is how to set up IIS for secure transactions. Often the reason for doing this is not so that users can enter details such as credit card details, but so that an administrator can access a web-based administration page. The page will ask for their password and, unless it is being hosted on a secure SSL web server using https, then this will be sent as clear text and so could be ‘sniffed’ by any machine on any network that the data passes through. Encrypting this information with 64-bit, or preferably 128-bit, encryption is a safe way of sending sensitive data over the Internet. This does not mean that unsafe passwords that are of short length and consist of recognisable words can then be used – they shouldn’t, as even when encrypted they represent an easy target. The most common route to security is to purchase a certificate from VeriSign or a similar company, but if all you want to do is create a secure path for administrators, you can, under Windows 2003, create a ‘self certificate’ for free. This certificate will be just as secure, but users will not be able to check the owner of the certificate against a global certificate server.
To create such a certificate, the first task is to download the IIS 6 resource kit from www.microsoft.com/ downloads/details.aspx? FamilyID=56fc92ee- a71a-4c73-b628- ade629c89499& displaylang=en. This will install a variety of tools on your server. After the install has finished, go to Start | Programs | IIS Resources and select SelfSSL, which will open a command box where you type the command line to add a selfSSL certificate to a website. The basic syntax is:

Selfssl.exe /V:365 /S:1

There are more options but that’s about the minimum, where the /V switch sets the number of days before the certificate expires and the /S switch tells which site to apply the certificate to. This number is the site number and can be found from IIS Manager or, better still, from the IIS Metabase explorer, which is also part of the IIS Resource Kit: the default website is 1 for instance.

One thing to watch out for is that if you have more than one site on your server, you will find that the website will not start after applying the SSL certificate with selfSSL. Before you email us with death threats, please take a look at the properties of the website having problems, and in the tab marked ‘Web Site’, click on the advanced button next to the drop-down that allows you to assign an IP address to the site. When the advanced screen comes up, you will notice that the entry for port 443 (the secure https one) has ‘default’ assigned to it, which means ‘all unassigned IP addresses’ and this can cause a conflict with other sites on this server and so stop the site from starting up. Just change this entry to the IP address for the non-secure port 80 and then start the site from within IIS Manager and all should be okay.

When you point your browser to a website that’s been secured by a selfSSL certificate, you will get a security alert dialog stating that the name of the security certificate is invalid or does not match the name of the site. This is because these certificates are normally used just for testing, but it is a small price to pay for getting a free certificate. You now have an encrypted website, and you will notice a padlock at the bottom of your browser – clicking on this will reveal the details of your certificate. Use this secure channel only for administration purposes, because the performance hit on the web server when it has to encrypt and de-encrypt all the traffic is considerable, and it wouldn’t be a sensible configuration on a live public website where encryption of all the data wasn’t needed.

Moving blues

After moving a number of websites to new Windows 2003 servers, we ran a series of tests; it was during this testing that we found these sites were no longer able to send emails from their ASP code. On investigation, it was found that this code used CDONTS (Collaboration Data Objects for NT Services), and this is no longer shipped with Windows 2003. It is now recommended that you should code using CDOSYS, which offers yet another method of coding email and collaboration objects. Microsoft possibly has even more ways to do this than it has for accessing databases, and that’s saying something. All these various systems have their strengths and weaknesses, and the code of each is incompatible with all the others. For our particular web server, with its many websites, rather than examine the code on all the sites, change it and then test them all again, it was felt to be an easier route if we could make CDONTS work on Windows 2003, and the solution for how to do this proved almost too easy. On a Windows 2000 server, look in the systemroot\system32 folder for a file called cdonts.dll and then copy this to the similarly named folder on your Windows 2003 server. Next, you need to register this DLL so that the operating system knows about it and how to use it. To do this, open a command window on this server and run:
regsrv32 systemroot\system32\cdonts.dll

After you have read the message saying that registering the DLL was successful, your server’s CDONTS code should then be able to run. It is probably worth going over your code at some later date and converting it to CDOSYS when you have the time, as we have found that it seems more reliable than CDONTS (which on occasions seems to put extra line breaks in emails for no apparent reason).

Discriminating Websites

Have you ever wondered why the Powers That Be are so insistent that websites should be made accessible to disabled users? Unless we are missing something, just about all that the web designer can do to help is make all the fonts scale properly and make the pages readable by screen readers; also, the only disability that such design can assist with is the blind or partially-sighted user. Everyone would agree that the standard techniques of scaleable fonts and Alt tags on all graphics should be applied to every website design as a matter of course.

As for helping with other forms of disabilities, we are at a loss to know what can be done at the design stage to help such users. If you know otherwise, please email us and we will follow this up in a later article. Consider the scenario in which your site is offering a lower price, or some exclusive service to online users – if that site does not have all the required accessibility features applied to it, then a disabled user could quite rightly claim that you are discriminating against them by excluding them from these lower prices or special services. This is certainly something that needs serious thinking about when checking your sites, and we are already noticing our clients getting nervous about this and requiring their sites to be checked to see whether they comply. More work for us all…