asp : wackomenace

Server-side errors in ASP

26.02.2008 10:08 PM | Tags: asp, internet |

You would have hoped that Classic ASP was a long-dead dinosaur, but not so. Recently, I have been working on a large website written mainly in Classic ASP (VBScript) and I’ve been getting to grips with some of the absolutely atrocious code that I’ve seen.

There is a lot of database interaction on the site, and a lot of the server-side SQL is written in a way that basically invites injection attacks. As well as that, database connections are arbitrarily unclosed and input is mainly unchecked. This is code that I would have been comfortable with 10 years ago, when people on the web were more trustworthy.

In order to get around some of these problems, some code was inserted at a later date to force ASP to carry on processing after an error. This was mainly put in to stop errors from showing up on a production site. However, the side effect is that when there is a fatal error, processing carries on infinitely, or rather until the time hits the timeout. When a lot of these happen at the same time, the server can easily be slowed down, and in fact this was a problem we experienced recently with an attempted denial of service attack.

At the moment, I am working on migrating a lot of SQL code to use parameters which fixes a lot of the errors, such as type checking, quotes and prevention of injection attacks. As well as this, the cloaking code has been taken out, and instead we have a 500 error page which sends an email with the error. At least with this, users gets to see a meaningful error and we get to know what happened without the server going down.

As a result, we initially received a massive number of error messages which would have otherwise been hidden. I spent a lot of my time rummaging around legacy code fixing these errors, which consisted mainly of variables not being declared before being used and form input being too long or of the wrong type. However, these errors have now died down and it’s good to know that we now have a site which has less errors and better performance.

ASP vs PHP for long tasks

26.07.2007 11:32 AM | Tags: asp, automation, php |

Yesterday, I got a good taste of what it’s like for a programming language on a web server to be handed a massive task to complete.

I was tasked with automating emails to subscribers of a vacancies alert service. The script as it stood was run manually once a day just before the end of work, and this script (written in PHP) would query the SQL server for details of subscribers and their preferences, and then compile individual emails and send them off. With hundreds of subscribers, this is quite a task. Nevertheless, the script took around 4 minutes at the most.

The preference was to move this script from the desktop to the server and automate it with a cron job. However, the database it interacts with is stored in MSSQL, and the way that the system is set up does not allow PHP access to MSSQL; only ASP.

I decided to re-write the whole script in ASP, upload it, test it, and then create a cron job to run it daily. With a few bumps and scrapes, I managed to port the script, but when I started to test it, the script timed out. OK, I thought: the automatic timeout is 90 seconds, which is not enough for this script. I increased it to four minutes (the length of time the PHP equivalent took), but it still timed out. Then I went to 6 minutes and the same happened. It was then that I realised that until timing out, the script would also bring down the whole site. This was unacceptable, and therefore we decided to revert to a desktop script, albeit automated with Scheduled Tasks in Windows.

This brings me neatly to the conclusion: ASP is much slower than PHP for running equivalent scripts, and its inefficiencies really showed up in this test and taught me a valuable lesson about using web scripts for very long tasks.