ColdFusion 10 REST API: site-wide error handler (AbortException) gets called when returning file

Question

I'm using ColdFusion 10's new REST API. At one of the endpoints, I'm returning a file like this:

<cffunction name="getFil"
            access="remote"
            httpmethod="GET"
            restpath="{id}/fil"
            returntype="void">
    <cfargument name="id" required="true" restargsource="path" type="numeric" />

        <cfprocessingdirective suppresswhitespace="no">
            <cfheader name="Content-Disposition" value="attachment; filename=foo.pdf" />
            <cfheader name="Content-Type" value="application/pdf"> 
            <cfcontent file="C:/some_path_to_file/foo.pdf" deletefile="no" />
        </cfprocessingdirective>

</cffunction>

It works perfectly and responds with 200 OK, following by the file in the response body. Even though the response is fine, the site-wide error handler gets called and the error message looks like this:

[coldfusion.runtime.AbortException : null] null <br>The error occurred on line 124.

The client never sees the error, but my email service sends out a notification email to the developers when the site-wide error handler is called. Anyone know what this AbortException is and how to prevent it?

Answer 1

I suspect it's the case that some CFML tags which halt processing (like <cfcontent> in this case) seem to use the <cfabort> code to do so. I can't rememeber how to repro it now, but <cfabort> does raise an exception under the hood (and and AbortException sounds about right), but ColdFusion for the most part suppresses it. REST requests don't use the same servlet as normal CF requests, so perhaps it's less good at suppressing it?

If you (for testing purposes, temporarily) remove the <cfcontent>, I would expect the exception to not occur.

I feel I've been a bit vague with some of the detail here, but I'm not in the position to give it a thorough test just now. Sorry about that. When I find time I'll try to firm things up and sound more definite about it.

Answer 2

I cannot argue with Adam's answer as it seems to make sense. Perhaps just catching that specific error (if you can) and suppressing the emails will suffice for you. But I did a little searching and possibly found a different approach you could try. Instead of using <cfheader> and <cfcontent> tags just return the actual binary data for the PDF from your service. See this blog article about it:

CF html to pdf service - consume from node.js using rest api

Don't worry about the node.js reference as the given example does not use it. They just link to a node.js example as well.

In their example they are passing the data to the service but it should be trivial for you to instead read your PDF file and return that data.