Copy link to clipboard
Copied
I have a website that worked fine with Coldfusion 10 and now I have updated to Coldfusion 11 and this code doesn't work:
<cfheader name="content-disposition" value="inline; filename=#vPublicFile#" />
<cfcontent type="application/pdf" file="#DownloadFolder##qryDownload.fileNameOnserver#" deleteFile="no" />
If I type in the URL directly to the PDF file it loads fine, but if I try to get it through this code then I get the message "failed to load PDF document". Even if I change the code to allow me to save the file, I get a saved file but it won't open in acrobat.
I know the code is working code, I tried it with Coldfusion 10 again just to make sure. Something about 11 is stopping it from working. Any ideas?
Copy link to clipboard
Copied
Are the paths exactly what you expect? Check
<cfoutput>
#vPublicFile# <br>
#DownloadFolder##qryDownload.fileNameOnserver#
</cfoutput>
<!---
<cfheader name="content-disposition" value="inline;filename=#vPublicFile#" />
<cfcontent type="application/pdf" file="#DownloadFolder##qryDownload.fileNameOnserver#" deleteFile="no" />
--->
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Perkley wrote:
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.
Copy link to clipboard
Copied
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" />
Copy link to clipboard
Copied
I have tested the code, on CF10 and CF11. It renders fine in browser.
Regards,
Ait Kumar
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Hi!
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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:
<cfoutput>
#vPublicFile# <br>
#DownloadFolder##qryDownload.fileNameOnserver#
</cfoutput>
Copy link to clipboard
Copied
POSTER.pdf
D:\myfilelocation\Poster.pdf
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.
Copy link to clipboard
Copied
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:
http://127.0.0.1:8500/workspace/cf11_proj/test/?someVar=5
http://127.0.0.1:8500/workspace/cf11_proj/test/index.cfm?someVar=5
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.
Copy link to clipboard
Copied
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!
Copy link to clipboard
Copied
Perkley,
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?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
http://test.com/index works
http://test.com/index?foo=bar fails
Without URL rewriting
http://test.com/index.cfm works
http://test.com/index.cfm?foo=bar works
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>
Copy link to clipboard
Copied
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:
"/?go=viewPDF" fails
"/index.cfm?go=viewPDF" works
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.
Copy link to clipboard
Copied
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:
Copy link to clipboard
Copied
This is absolutely an IIS connector issue.
Copy link to clipboard
Copied
I can confirm the connector issue. Any solution is appreciated!!
Copy link to clipboard
Copied
Update 15 has fixed this problem for me.
Copy link to clipboard
Copied
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:
/apps/news/picture/index.cfm?id=123
but this one will only return 4 bytes of data:
/apps/news/picture/?id=123
The script on this page is reading binary data from a database BLOB, then returning the content via:
<cfcontent type="image/jpeg" variable="#imagedata#">
Copy link to clipboard
Copied
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:
http://hostname/directory/image.png -> http://hostname/directory/index.cfm?image=image.png
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: