If you may be running a CFML image processing tag or function, which obtains its source image from a URL, you might get this error, “ColdFusion was unable to create an image from the specified source file“. Some good news is that the solution may be quite simple–though it was not obvious to me, at first.

TLDR; In my case, the solution was simply to change the URL for the image from using http to https (the CFML image functions don’t follow redirects, as I will explain below).

This error stumped me for a few minutes, and while I found few discussions of the error on the web, none proposed this as the solution. Once I found it, I wanted to share it here so others might find it in the future.

But I realize that one change alone may not be the solution for you. Here are two others to consider if faced with that error:

• first, visit the image URL in your browser. If the image DOES work, copy whatever URL the browser now shows and try using that in the CFML image function. It could be that the server serving the image has a redirect to some entirely new-looking URL. If that works, great
• if visiting the url in a browser works but that URL still doesn’t work in your CFML, try visiting the image URL in a browser ON the server. Does it work from there?
  • If not (but it worked in a browser OFF the server), there then is some reason that that URL can’t be reached from the server
  • If it CAN be reached from a browser ON the server but still not from WITHIN your CFML, then that’s some other problem (having nothing to do with image processing in particular, it would seem)
  • Either way, such a failure to reach the image from the server is beyond the scope of this blog post

As for why the first couple of solutions might work and be needed, read on.

Background

As some readers may know, some CFML image tags and functions allow you to name a URL as the source of the image. In that case, the obtaining of that image happens within CF, with underlying java httpclient code acting as “the browser”. That’s a good thing, but there are ways it may not act like your own browser.

In my case, the problem was that the URL in use was in some older code that was using http for the image, and got this error.

But when I visited the URL in a browser, I noticed that the server serving the image offered a redirect to the https url, and that then DID work in the image function, and thus that was the solution for me. But I’d not found that offered as the explanation and solution, when I searched for others hitting this error.

But why didn’t the URL work in the image function, when it worked in a browser?

The problem is that while your BROWSER is designed to follow redirects (an http status code sent to your browser from the server, with a URL of the “new” page to go visit), the java-based httpclient browser underlying the image functions doesn’t do that by default, or at least the functionality to allow that is not enabled by the CF engine’s call to that httpclient library.

FWIW, one may notice that cfhttp tag (and its script equivalent) would NOT have the same problem. It WAS specifically designed to follow redirects, at least up to a maximum of 4 redirects (per the docs, and it also offers an option to tell it NOT to follow such redirects).

A bug report/feature request about this

We could perhaps argue that the CFML image processing tags and functions ought to ALSO allow for following redirects by default. I have created a bug report for it: https://tracker.adobe.com/#/view/CF-4205714. I was torn as to whether it should be a bug report or a feature request. I do think that most would reasonably expect that these image tags/functions would follow redirects, just like cfhttp (and browsers).

If you agree this situation could be improved, add your vote there, where you can also comment (and/or here).