Are the paths exactly what you expect? Check
<cfheader name="content-disposition" value="inline;filename=#vPublicFile#" />
<cfcontent type="application/pdf" file="#DownloadFolder##qryDownload.fileNameOnserver#" deleteFile="no" />
Yes, the paths are correct. I did check that before posting. Like I said, it works in CF10. It shouldn't work in CF10 if the files were not found. As far as I understand the filename in cfheader can be whatever I want, right? That is just how the user receives it.
Like I said, it works in CF10. It shouldn't work in CF10 if the files were not found.
The reasoning behind my suggestion is that there usually are subtle changes that may occur when you change versions. For example, there just might be a character in the path, that is compatible with Coldfusion 10's settings but not with Coldfusion 11's. This is more a process of elimination than anything else.
You could do two more tests to rule out the obvious. Firstly, the 'inline' attribute implies the PDF is to be opened by the browser. So, to rule out browser quirks, open the CFM page in different browsers. Any change?
Secondly, test by swtching from 'inline' to 'attachment'. Any improvement?
As far as I understand the filename in cfheader can be whatever I want, right?
Yes, any filename, whatever_you_want.pdf, will do.
I have tried multiple browsers and attachment instead of inline. Acrobat Reader won't open the file, it just gives me a corrupt file error. I have tried filenames with no spaces, it just will not work in CF11. Anybody else having success with a PDF working in CF11?
Here is a sample of my code with the variables output:
<cfheader name="content-disposition" value="inline; filename=POSTER.pdf" /> <cfcontent type=" application/pdf" file="D:\myfilelocation\Poster.pdf" deleteFile="no" />
I have tested the code, on CF10 and CF11. It renders fine in browser.
Well I have tested it on my production server and my local development server and neither work with CF11. Could it be something with IIS7? Or some other security with the file folder? I can type the url to the file directly and it opens the file fine, so I know it is not being blocked that way. I will try my mobile phone and see if that does anything different.
Okay, I am getting somewhere, I have found that if I pass a URL in the parameter then it fails to load the pdf. If I go straight to the directory and do my code then it works. However, I need to pass a URL string to define the file depending on what they click on. I am trying to see if it is a variable name, but that doesn't seem to be the case. Still looking into it.
UPDATE: This is what my link was looking like: http://www.mywebsite.com/download/?file=encryptedstring
I found that in order for CF11 to work I need to actually define index.cfm, like this: http://www.mywebsite.com/download/index.cfm?file=encryptedstring
I prefer the non index.cfm way, but at least I found a fix for now, but I will keep looking into it and see if I can get it to work without showing index.cfm, I am not sure what in CF11 caused this.
This is my solution right now:
My link was something like this: www.website.com/download/?file=encrypted, which fails.
If my link is like this: www.website.com/download/index.cfm?file=encrypted, then it succeeds.
Because I don't want to show index.cfm, I used ISAPI ReWrite and now have this URL: www.website.com/download/encrypted, which in turn processes it as index.cfm?file=encrypted, and that works fine.
However, I have some other areas where I do the same type of thing to generate a PDF and having the same issue.
Is someone else willing to try a similiar link: www.website.com/download/?anyparam=anything and see if they get the same problem. To me this seems like a bug.
Your problem is with IIS and not with Coldfusion. The way you wrote your url rewrite not include the call but you can make it a rule to rewrite these parameters for you. I had such a problem with the cf chart and had to create a rule for him and even mapping of the CFIDE directory as a virtual directory to function internally.
I am not exactly sure I follow what you are saying. In CF10 it worked fine, in CF11 it doesn't. I know it still runs index.cfm because if I give it a bad filename it crashes and shows me that it can't find the file, and when I do have the filename correct it does give me a file, it is just corrupt. So whether I include index.cfm or not in the url they both run the file, one just delivers the file fine and the other one doesn't.
cfchart works fine for me. Again, maybe I just don't exactly understand the area you are referring to.
There appears to be some confusion between URL, which pertains to the client, and path, which pertains to the server. To return to the original question, could show us the result of the following:
I don't really want to reveal my file structure for security, but it is correct and I am not sure that it has anything to do with the URL, the URL runs the page or doesn't and the file either exists or it doesn't.
I did output the values with calling the page both ways (/?file=encryptedtext or /index.cfm?file=encryptedtext) and they both output the same values. Just a note, everywhere else on my page that I use /?var=value it works fine, no problems, it is just when trying to give a PDF file then it is not liking it for some reason.
I now realize the question has moved from the cfheader-cfcontent code to the structure of the URL. In my attempt to reproduce the issue, I put the code
<cfheader name="Content-Disposition" value="inline; filename=myReport.pdf" />
<cfcontent type=" application/pdf" file="C:\ColdFusion11\cfusion\wwwroot\workspace\cf11_proj\files\report.pdf" deleteFile="no" />
in the file C:\ColdFusion11\cfusion\wwwroot\workspace\cf11_proj\test\index.cfm. I then ran the following URLs in turn:
Both worked as expected, opening the PDF in the browser. I tested on Chrome, Internet Explorer 11 and Firefox 30. I am on Coldfusion 11, and use the built-in web server.
Okay, well I launched CF11 on my production server, which is a hosted setup by another company and found the problem, so I tried on my own setup on my development system and the same problem. Both setups do have IIS running though, so maybe it really does have something to do with that. Or I also have ISAPI ReWrite running and maybe that is interfering, I will try to check that and let you know. The strange thing is that it works with the same IIS or ISAPI ReWrite code on CF10, so go figure!
It appears that this issue has made its way down to ColdFusion 10 when Update 14 was rolled out. Did you ever find a solution for this on your machines other than putting index.cfm in the URL?
No, and as you see from the responses above, others are not having the issue. I just went forward with the ISAPI ReWrite option. But it's too bad that it is effecting CF10 now.
Thanks for the reply!
We did a pretty significant amount of testing and confirmed that as you expected, the issue only occurs when we use URL rewriting AND have a query string in the URL.
With URL rewriting
Without URL rewriting
We are using the IIS 7 rewrite module 2.0, though, not a manually installed ISAPI module. If you are having luck with the ISAPI module we will have to give that a go.
I really have to wonder what kind of behind the scenes madness is occurring with that query string...
Perhaps you could try testing again under a similar scenario described above?
Our setup is Server 2008 R2 Standard, IIS 7.5.7600.16385, and MS' IIS Rewrite Module 2.0
Note: In the cases where we ARE NOT using URL rewriting the template has the cfdocument tag within it. In the cases where we ARE using URL rewriting the template we are redirecting to has the cfdocument tag in it.
Simple cfdocument tag we are using:
<cfdocument format="pdf">Test PDF</cfdocument>
I'm seeing this issue after applying CF10 update 14 as well. We're on IIS 7.5.7600.16385 but do not have the IIS rewrite module installed. The specific issue we're seeing is that this URL will work:
but this one will only return 4 bytes of data:
The script on this page is reading binary data from a database BLOB, then returning the content via:
<cfcontent type="image/jpeg" variable="#imagedata#">
I am having a simulair issue with cfcontent.
In my CF9 with IIS7 it is still working, with my new server with CF11 and IIS8 it is not working.
I use the same web.config in both old and new server (and also the same CF code)
The Rewrite URL is set like:
In the index.cfm i do the following:
<cfheader name="Expires" value="#GetHttpTimeString(DateAdd('d', 100, Now()))#">
<cfcontent type="image/png" file="#customPath##attributes.image#" />
While on the old server this shows the image, on the new server it is failing (nothing is shown).
When i just do a <cfdump var="test"/> in the index.cfm, it shows the text. (So it runs through the index.cfm).
But when i change it to cfcontent it fails.
Workaround it so turn off URL Rewriting and call the original URL:
Did you find a solution? Just installed cf10 update 14 today and have ran into this issue.
Works fine when I add "index.cfm" to the url, but fails without it:
I running iis 7.5. I'm guess it's a iis connector/tomcat issue since the update included an updated tomcat server.
I did notice that when I don't include "index.cfm" a "connection:close" response header is added.
I think that this is a iis web connector issue.
One of the worst cf update bugs I have ran into.
I have a lot of binary data served up with cfcontent, I never include "index.cfm," and almost always have query string params.
<cfheader name="Content-Length" value="#variables.FileSizeBytes#" />
<cfheader name="Content-Disposition" value="inline;filename=#variables.FileName#" /> (inline vs attachment makes no difference)
<cfcontent type="application/pdf" file="#variables.File#" />
/test/ - works
/test/index.cfm - works
/test/index.cfm?getPDF=1 - works
/test/?getPDF=1 - fails
Connection:close response header value there everytime it fails:
- Date:Wed, 12 Nov 2014 20:59:55 GMT
- Response headers when it works:
- Date:Wed, 12 Nov 2014 20:55:53 GMT
Have you tried different versions of the browser? I am finding a similar issue with ColdFusion 11 running in IE8..It works fine in FireFox and in IE10...
This is absolutely an IIS connector issue.
- I deployed CF10 HF 14 to a dev box and didn't update the connectors. This still works for me.
- I deployed CF10 HF 14 to a staging box and did update the connectors. I have this exact issue as described above.
I can confirm the connector issue. Any solution is appreciated!!
We are also facing problems after updating to CF10 Update 14 with this issue. We do notice that the behavior is different based on the browser used on the client side. Photo uploads no longer work in Mango Blog 1.7 when using IE, but do work when using Google Chrome.
And provide any details so that they can "VERIFY" it.
Update 15 has fixed this problem for me.
Is this still a thing? I'm experiencing this on CF11 presently.
I can't make
<cfcontent file ="#literalFilePath#" type ="image/jpeg" />
work through a redirect, though it works fine when loaded without it.
I'm working with images on this task. Will upgrading to the latest isapi_redirect.dll do the trick?
Thanks for your feedback!
Is anyone still experiencing this issue or have a good fix for it?
Currently on Coldfusion 11 Update 7 and IIS 8 and experiencing the exact behavior as noted above. Having to implement a workaround for this would cost us quite a bit of development time.
Sorry didn't seem to get notified of this message and just saw it. I am using Coldfusion 11 Update 7 and I still see the problem.
Still having this issue on ColdFusion 11 update 7 with latest connector installed when using iis rewrites with query string parameters. Anyone else still having the problem? Know of a quick fix other than writing a workaround? IIS connector settings? Thanks!
I recently ran into this same issue on ColdFusion 2016 (update 3) on Windows 10 and also on Windows Server 2012.
I can confirm based on what previous posters have said that when IIS rewrite is enabled the wrong HTTP response headers are sent to the browser. Additionally, the wrong content length is also sent. I believe that this is a connector issue and not IIS.
Here is an example of the proper response header when accessing a file (e.g. /test/file.cfm?filesID=1)
Cache-Control:no-cache, no-store, must-revalidate, max-age=0
Date:Fri, 18 Nov 2016 01:16:02 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Here's an example of the invalid response header when accessing a file via IIS rewrite (e.g. /test/file/1/)
Cache-Control:no-cache, no-store, must-revalidate, max-age=0
Date:Fri, 18 Nov 2016 01:16:39 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
There are two things wrong with the response header. The first is that "Connection: close" has been added as well as an incorrect content-length which is why the file you wind up downloading is a corrupted (incomplete) version of the PDF you wanted.
I created a bug in the adobe bugbase here: Bug#4197947 - <cfcontent> fails to serve PDF files when using IIS rewrite
Please vote for it. Unfortunately since this issue is difficult to replicate if anyone can add their own replication code to the bug I'm sure it would be a big help to the dev team.