CFHTTP Error Handling for Status Codes

We’re discussing some refactoring before releasing a cfpayment 1.0 and one of the things I’m working on is figuring out when to use ColdFusion’s in-built error handling and when to use HTTP status codes. Currently we use the throwonerror option for CFHTTP which results in issues like 404 throwing an exception. This works but as more and more services expose RESTful APIs which use status codes other than 200 to communicate results, this is not perfect.

That got me to thinking… what status codes does ColdFusion throw an error for when throwonerror is set to yes? Here’s the list for every HTTP status code:

CFHTTP with throwonerror=”yes”

I also ran it with throwonerror=”no”, which has almost the results you would expect with the exception of code 411:

CFHTTP with throwonerror=”no”

Notice Status Code 411 doesn’t return a numerical status code but rather a string “Connection Failure. Status code unavailable.” The FileContent is set to “Connection Failure” while all other status codes are left blank (assuming that the request doesn’t return any data, as my test script does). Good to know.

Problematic SSL Certificates

For processing credit cards and payment processing transactions in general, the most insidious error I have run into is the “I/O Exception: peer not authenticated” error. This basically means ColdFusion is unable to read and authenticate the SSL certificate and initiate a secure connection. Generally this is either a self-signed certificate or, these days, a wildcard SSL certificate. Interestingly, ColdFusion handles these scenarios a little bit differently depending on how throwonerror is set:

In summary, using throwonerror=no looks reasonably safe but you still must account for the catch-all COM.Allaire.ColdFusion.HTTPFailure. My battle-tested code (which has processed more than $15MM) suggests you also need to check for coldfusion.runtime.RequestTimedOutException which is a different kind of exception when CFHTTP times out or the page times out.