I would think this is just a bug. should be looking at the binary data, not the string in the source value. I recommend raising a bug in the bug tracker: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html. Refer the number back here, and I'll make sure it gets on the CF9 team's radar. -- Adam 2009/10/2 MPDirector >]]>

This is probably one more for the Coldfusion Team at Adobe to answer but

I'd like to post this here in case anyone else has run into this and has

discovered a fix.

>

I'm using cfimage and a .NET webservice that returns an image and then

applying some more cfimage functions before saving a new version of the

image to my server. The for this import of the image from the webservice is

as folllows.

>

*<cfimage source="

http://service.mywebsite.com/images/showimage.ashx?type=cover&bookid=#VARIABLES.custNumber#"

name="topImage">*

>

>

It works great, until I updated the server with the latest Hot Fix that was

released 9/2009. It then fails with the following error:

h1. The ashx image format is not supported on this operating system.

>

>

I removed the Hot Fix from the server and it works fine once again. I

started wondering if this would be the case with CF 9 as well so I tested on

my local machine's install of CF9. Indeed it returns the same error. This

being the case it appears to be an intentional decision on the part of the

ColdFusion team to introduce this new functionality.

>

I've already verified that the webservice is returning a content type of

img/jpeg in the header. It appears that Coldfusion is evaluating the file

extension of the source attribute prior to even connecting to the

webservice.

>

Ray Camden has already advised trying to "trick" coldfusion by ending the

source location with "&crap=.jpg". Great idea but no dice.

>

Any answers as to why this appears to be the future direction of cfimage's

functionality, or any fixes to get it to recognize .ashx would be greatly

appreciated.

>

Thanks.

>

-Chad

>