We all know that showing raw error messages to end users is a bad idea. The easiest way to get around this in ColdFusion is to add a site-wide error handler in the ColdFusion administrator. Another option is to use ColdFusion's cferror tag to display a custom page when an error occurs. One thing you may not think about however is returning a proper HTTP status code from your error pages. This really bit me over the past few weeks so I though I'd share a little about what I've learned.
Over the past three weeks I've been involved in series of load tests against a new cluster we built out for the application I'm working on. We hired an outside company to run the load tests as we didn't really have the resources to do it in-house. For the first test we ranColdFusion pretty much straight out of the box. The results were border-line acceptable, but I knew we could make some changes to the JVM and administrator settings and do better. I made the changes and we ran another test and got phenomenally better results. Now I expected some performance improvements, but not on this scale. This led me to do some investigation...
Before each test we restore a version of the database which has the base data the load test scripts need to run. The application uses MSSQL Server's full text indexing, so after every restore we need to rebuild those indexes. Several areas of the application, and thus our test scripts, use that full text index so if they are not built or populatedSQL Server will throw an error. Well it turns out the developers of our application actually thought about this and handled that exception with a nice error message saying you need to have the site administrator check the indexes. The problem is the error page returned a 200 OK status code. Why was that a problem? Well we forgot to rebuild those indexes before the test in question. The company running the test only knew that we had made some changes to the application and we expected to see some performance improvements. When they ran the test and saw all our pages coming back with a 200 OK status they assumed everything was fine. Little did they know that the application was performing so well because it wasn't doing what it was supposed to do!
Now I wish I could say we learned our lesson, but this actually came up again on the next test we ran. We fixed the full text indexes, but our application talks to another, somewhat flaky, server to do certain tasks. It turns out the developers knew that this server may go down on occasion so they wrote another nice error page to handle that as well. It was only after the test that we discovered the service was down and our load test was basically invalid.
Moral of the story: if you are going to use custom error pages consider using the cfheader tag to set appropriate http status codes when you can. Something like the following should do the trick:
NOTE: If you are using ColdFire you might want to keep in mind that, unless you have called cflocation or cfflush, your page will always returns a 200 status code. I'm going to talk to Ray and see if that can't be fixed.