tracker issue : CF-4205714

select a category, or use search below
(searches all categories and all time range)
Title:

CFML image tags and functions that accept URLs should follow redirects, like cfhttp does

| View in Tracker

Status/Resolution/Reason: To Fix//Investigate

Reporter/Name(from Bugbase): Charlie A. / ()

Created: 10/29/2019

Components: CFIMAGE

Versions: 2018

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: update 5 (but not new to even cF2018) /

Priority/Frequency: Normal / Few users will encounter

Locale/System: / Windows 10 64 bit

Vote Count: 3

If one uses any of the various CFML image processing tags or functions that accept URLs for the image to be processed, those tags (like cfimage) or functions (like imageread, imagresize, etc.) will fail with an error, if the URL results in a redirect from the server serving the image.

This could happen when the server changes from using http to https. In that case, while a browser would detect and follow that redirect and show the image, the CFML functions will NOT. Instead, they will fail with the error, "ColdFusion was unable to create an image from the specified source file". 

That's not at all an obvious error, and I have created a blog post on it to help others in this situation (but since I want to point to this ticket in that post, I will come back and offer the URL to the postin a comment).

I do realize that the feature to read images via a URL relies upon the underlying java httpclient library, and that does not follow redirects by default (per https://stackoverflow.com/questions/5169468/handling-httpclient-redirects).

But note that the cfhttp tag (which is ALSO built upon httpclient) DOES automatically follow redirects (up to 4 times, per the docs, unless it's told NOT to).  

Is there any reason that the CFML image processing tags and functions can't be changed to also follow redirects, unless told otherwise? 

And I have not filed this as a feature request, because really I'd think people would EXPECT that the image tags/functions would follow redirects, just like CFHTTP does. Or at least, they would expect that if it failed, the error message would be more clear than it is right now.

Attachments:

Comments:

Here's the blog post I created, related to this: https://coldfusion.adobe.com/2019/10/image-processing-error-and-solution/\
Comment by Charlie A.
31701 | October 29, 2019 06:19:24 PM GMT
Hi Charlie, You mean to say that image is accessed over https protocol and ColdFusion image function unable to perform any action. e.g. {code:java} <cfscript> myImage=ImageRead("https://localhost:443/SNS.PNG"); ImageWrite(myImage,"awssns.gif"); </cfscript> {code} If I misunderstood the message , then can you please provide sample code to identify the issue?    Regards, Mukesh
Comment by Mukesh K.
32049 | January 30, 2020 10:35:53 AM GMT
Mukesh, thanks for responding, but no, you have indeed seriously misunderstood. I am NOT saying that cf image tags and functions cannot process https urls. I'm saying the can't follow REDIRECTS, which often happen these days if one requests an image url via http vs https. Here is a multi-step example demonstrating the point, but the key failing is the last example : 1) visit this url in your browser, and note how your browser changes to using https (because the web server told it to redirect there) : http://cfdocs.org/apple-touch-icon.png 2) Now do a cfhttp to that same http (not https) url, and note that it too works, because cfhttp follows redirects by default : <cfhttp url="http://cfdocs.org/apple-touch-icon.png"> <cfdump var="#cfhttp#"> The dump shows an image object (byteareay) was returned. 2a) if you add redirect="false", the cfhttp still "works" but the dump shows a 301 (redirect) was returned : <cfhttp url="http://cfdocs.org/apple-touch-icon.png" redirect="false" > <cfdump var="#cfhttp#"> 3) Now instead use an image tag or function to access the same http url, and note that the request fails: <cfscript> imgObj = imageRead("http://cfdocs.org/apple-touch-icon.png"); cfimage(action="writeToBrowser", source=imgObj); </cfscript> But if you change the to use https instead, it works. So again, why don't image tags and functions follow redirects by default like cfhttp does? This is important as more and more sites switch to https, and use redirects to force ALL requests--including for images--to switch to https, thus breaking any cf code that accesses such images via cfml image tags or functions. Make sense now?
Comment by Charlie A.
32050 | January 30, 2020 02:16:59 PM GMT