Using The OnError() Event Handler Implies A "200 OK" Response Status Code
Posted April 29, 2009 at 9:16 AM
Special thanks goes to David McGuigan for pointing this out to me and I am just passing it on. This is just a minor note for anyone who perhaps hadn't thought about it (just as I had not thought about it); when you use the OnError() event handler in ColdFusion's Application.cfc, a "200 OK" status code response is implied. By that, I mean to say that a page that would normally respond with a "500 Server Error" status code will respond with a "200 OK" status code if that raised exception is caught by the OnError() event handler.
You can, of course, override the status code from within the OnError() event handler; but the overriding value would be something like a 404 or a 401 error - you will never have to override with a 200. When you think about error handling and picture the OnError() method as the root-most "Try/Catch" block, then this makes sense. For some reason, however, I just always assumed that OnError() would create a 500 status code, but allow you to handle it gracefully.
Anyway, thanks David for teaching me some good stuff!
Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Newer Post
Thoughts On User / Page Request Security Model
Older Post
Ask Ben: Manually Enforcing Basic HTTP Authorization In ColdFusion
Reader Comments
Overriding the response code is something I do when I'm making AJAX requests. I find it far easier to create a callback method that responds to a 500 response than to try to tell the difference between an actual "200 OK" response and an error that's been given a "200 OK" response code.
$.02
@Matt,
I have nothing against overriding a response code. I'm only saying that when you use the OnError() event handler, it doesn't use a 500 error code for the error - it uses the 200. So, if you want a 500, then you have to do that manually.
Good to know, especially if monitoring a site.
@Matt,
One thing to keep in mind is that by fudging a 500 error, you are adding a 500 error to your logs. Which means any web site reporting tool such as Urchin will report these as errors within your sites. I have been on many a contract where monitoring and reducing the number of 500 errors is a requirement.
To that end, Ben's method of passing back a response struct for both successes or failures when using AJAX is a much better solution in that it allows us to process the errors just as easily (a simple IF statement in the success callback checking the flag), and doesn't artificially mess with the web site logs.
@Ben
Didn't mean to make it sound like you were saying not to. Just pointing out how I've used that in the past.
@Rob
True, but in this case that's not so much a problem. By the time the error hits the point where I override the response code, something has gone terribly wrong and I want to know about it. Overriding the status code makes it easier for me to detect these errors and allow the javascript to let the user know that something unexpected has happened.
