Can you please try out the following steps to help isolate the issue:
1. Try opening a PDF on your local system, in Internet Explorer 8/9. What is the behavior.
2. Try opening some other PDF at some other URL on Internet Explorer 8/9 such as:http://kb2.adobe.com/cps/837/cpsid_83708/attachments/Acrobat_Reader_ReleaseNote_9.4.2_8.2. 6.pdf
3. If possible, can you share a link currently not working on your customer's system.
Thanks in advance.
Thanks for your reply,
As to your questions:
- Try opening a PDF on your local system, in Internet Explorer 8/9. What is the behavior.
- Using a PDF that was saved when receiving the "File Download" window, the user/we can open the file without issue (both by opening through Reader 9.4.2 and through IE 8/9).
- This is also the case for every other PDF that they/we open from the local system, not related to our website.
- Try opening some other PDF at some other URL on Internet Explorer 8/9 such as:http://kb2.adobe.com/cps/837/cpsid_83708/attachments/Acrobat_Reader_Re leaseNote_9.4.2_8.2.6.pdf
- This link worked and the PDF file opened without issue
- If possible, can you share a link currently not working on your customer's system.
- Unfortunately that isn't possible. The file is generated based on user settings as well as being created on-the-fly (from memorystream).
- However, here is a link to a saved PDF generated from our site that had the "File Download" window issue - https://secure.confirmdelivery.com/MAILnet/EZAddressPDF.pdf
- When using this direct link, the file opens fine for us
We investigated further with other PDFs generated by our website (we have pages that create order forms, and other documents), and they all work fine. All the PDFs generated on our site use the same PDF generating software (Siberix ReportWriter) and are all generated from memorystream.
Below is the asp.net/vb.net code we use to post all website generated PDFs to our users:
Response.ContentType = "application/pdf; name=" & randomName & ".pdf"
Response.OutputStream.Write(pdfByteArray, 0, pdfByteArray.Length)
- Try opening a PDF on your local system, in Internet Explorer 8/9. What is the behavior.
Also seeing this issue. Windows Vista SP2 with IE8 and Windows 7 with IE8. PDF generation is also done on the fly, and streamed back to the client. With Reader 9.4.1, this was working fine. After 9.4.2 upgrade, now we get an IE file download block message. We can click "Download File", but then we get a message to Save the PDF, instead of the PDF opening in the browser window like it always has. After clicking Save, and saving it to the desktop, the PDF can be opened in Adobe Reader standalone. We have the Internet option in Reader set to open in the browser. The text of the Save message is: The file you are downloading cannot be opened by the default program. It is either corrupted or it has an incorrect file type. As a security precaution, it is recommended that you cancel the download.
Ditto for us. We are using a popular 3rd party web-based document management system which creates the PDF files on the fly. It is used internally by our employees and externally by customers. The system worked fine for all until the Adobe Reader 9.4.2 upgrade a few days ago. Please provide a fix/advice or some direction for troubleshooting this problem asap.
We are experiencing the same problem, as I mentioned below. I did some research and experimentation, and have a ... workaround. It's not completely satisfactory, but we will go with it until we have a complete solution. Perhaps the following will help others and spur some research in the right direction.
First, a quick review. The problem does not occur with PDFs located on disk; it only occurs with direct streaming of PDF data. Let's also note that the problem does NOT occur with other browsers, e.g. FireFox. So ... technically the problem is not an Adobe Reader problem and we're all on the wrong forum.
My specialty is databases and I'm certainly no expert in this area, but from what I'm able to gather the problem is instead with how IE is recognizing and responding to the MIME type of the streamed data. We're all setting the contenttype to "application/pdf" (or similar) or we wouldn't even be here. But I'm concluding that something - some windows update - has changed the way IE on clients or (in my case) IIS on the server is handling that data stream. If any of you experiencing this issue have servers other than IIS, then the problem is on the client side, I'd say.
Aaaaaanyway, the following articles are old, but helped me:
To cut to the chase, the workaround we're going with for now is to add the following to the http response header (this is C#/ASP.NET code):
That causes a popup dialog to appear asking the user to open or save the PDF, something that is familiar to most everyone. If the user asks to open the file, it appears in a browser window just as it did before this problem occurred. Again, this is a temporary solution, but at least the user can see the PDF data in a browser with one extra mouse click.
If an Adobe tech support person or anyone with more experience in this area knows the final solution, I'd LOVE to hear it. Please reply here or in email.
Thanks and good luck all.
Thanks for your reply,
Yes, it does look like this is an issue with streaming, but it's not a very consistent one. In my second post, I noted that I tested this with several of our streamed PDFs, and some of them worked, while others did not.
However, I do think this is an Adobe Reader 9.4.2 specific issue. I tested it myself: Before the Reader update, it worked correctly. After I updated to 9.4.2 it stopped working correctly. Also note that there were no corresponding windows or IE updates (I have my windows update service set to download but not install). And, again, this is an issue that isn't consistent... we have some streaming PDFs open correctly, while others do not.
It's good that you found a workaround that works for you for the moment. Unfortunatly, this does not perform in the way our clients expect, so this won't be a solution that we can use. I'm open to anymore suggestions, but we need for the PDFs to open directly, without any prompts, and without the client having to do anything on their end (which my be impossible at this point).
As I suggested in my opening post, we have found several workarounds to the issue, but they are not ideal (they fix the issue, but they require our clients to make the fix on their side, which is something that they shouldn't have to do).
Hopefully Adobe will release an update soon to correct this issue (along with some other issues it seems to be having).
@BillyBeeeeee: Just because it works in Firefox and not in IE doesn't rule out Adobe Reader as the cause of the problem.
Firefox uses the following dll: C:\Program Files\Adobe\Reader 9.0\Reader\Browser\nppdf32.dll
IE uses the files under: C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\
An initial fix for me was to replace the file C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll (version 126.96.36.199) with the version from Adobe Reader 9.4.1 (version 188.8.131.52) and this seemed to solve the problem. This wasn't a realistic solution though as I have no idea what security holes I might introduce by doing this.
After some monitoring of the headers from links with fiddler (http://www.fiddler2.com/fiddler2/) that worked versus the ones that didn't the common problem seemed to be:
Working: Content-Type: application/pdf
Broken: Content-Type: application/pdf;charset=UTF-8
Previously I had been monitoring IE with process monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) trying the different versions of the AcroPDF.dll loaded to find out what the difference was and I noticed with the new dll was trying to access "HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf;charset=UTF-8". After digging further I've managed to add this registry key:
Windows Registry Editor Version 5.00
This seems to fix it for me.
I know it isn't a solution for most of the issues on this post, and I don't know if your issues are related to the the headers but I thought it might help someone in the right direction or even better help Adobe fix the root cause.
Hi. Referring to the initial post - Why isn't upgrading to Reader X considered a recommended fix? Adobe Updater is indeed keeping me at Acrobat & Reader 9.4.2 without notifying me of the Acrobat/Reader X (v 10) upgrade.
(I did upgrade to Acrobat/Reader X (Ver 10) on a Win XP SP3 system with Creative Suite 3, which seems to fix this problem, but I'm holding off for Adobe's fix on a Win 7 64bit system with CS5 - both systems with IE8). ?
It is one of several workarounds that might be acceptable for some depending on the circumstances. For my company, however, we have thousands of clients, many of which do not have administrative privilages on their machines, and each with their own install/update policies that are managed by their own IT departments. This makes updating to Adobe Reader X a less than ideal solution in our situation.
@RStoddart: wow, impressive workaround... but it is fragile, so users beware. Uninstalling, patching to new dot-releases or upgrading major versions with that registry item in there will have, how do they say "undefined results". Of course, unless something better is found, it's the best so far.
It looks like the new version doesn't handle anything after "application/pdf". Unfortunate, and something that is important to fix.
Sorry I don't have any references for AdobeMimeTreatAs.
I just ran process monitor trying to work out what changed between the AcroPDF.dll in 9.4.2 and 9.4.1 and noticed it trying to access the key: HKCU\Software\Classes\MIME\Database\Content Type\application/pdf;charset=UTF-8. I then created the key and ran the same test again and as Reader found the key it then looked for the value AdobeMimeTreatAs. I created this value although without setting it as anything it didn't work. Given the name of the value I thought I would assign it "application/pdf" and it seemed to work. All I can guess is that Adobe Reader doesn't know what to do with the content type "application/pdf;charset=UTF-8" so checks the registry to see how it should be displaying the PDF and that key just tells it to use the "application/pdf" mime type.
As browserpdfman mentioned this is all undocumented and probably unsupported from Adobes point of view so I'm only using it as a stop gap until they fix 9.4.2 or we can move to 10.x. I've only tested it on Windows XP SP3 and IE8 so far so highly recommend anyone else considering using it tests it fully in their environment first. If it doesn't work for you then use fiddler or another application to monitor the reponse headers and look at the content type that comes down for the pdfs that work compared to those that don't.
For us upgrading to Adobe Reader 10.0.1 doesn't seem to be an option at the moment as they have managed to break protected mode and folder redirection (http://forums.adobe.com/thread/789500?tstart=0) so I'm very cautious about upgrading.
Thanks again. Interesting. So before 9.4.2, Reader did understand the charset suffix, now it doesn't. We discovered that charsets will vary -- on some sites it could be UTF-8, others ISO-8859-1 etc. The way to determine which charset (like already mentioned) is to capture the http response using a tool like fiddler.
I tried most of the steps on this read and it still does not work 100%. Here are my steps.
a) Header has already been set to application/pdf.
c) Added Response.Charset = null:
- Internet Explorer: Works
- Firefox: Works
- Chrome.. using the steps listed above: Does not work
- Safari: Does not work
Can you provide some additional information on how you were able to get this feature to work in Chrome/Safari?
This thread is discussing work-arounds to a specific issue caused by the combination of Internet Explorer and Acrobat Reader v9.4.2. The specific browser versions are Internet Explorer versions 8 and 9. (Neither older nor newer versions of the Acrobat Reader plugin for Internet Explorer have this specific issue; neither do any version of the Firefox plugins.)
Safari and Chrome may not even use a plugin to view PDF files (for example, on the Chrome developer channel). Although I am not sure what you mean by "does not work", the first thing I would verify is that a local copy of the PDF can be viewed using those browsers. If you can verify that it opens successfully and also determine that the plugin being used is Adobe Reader v9.4.2, you should be able to fix the problem by updating the plugin to v10.
If all of the above holds true and your users are stuck with v9.4.2 then more information is needed (the way things aren't working, HTTP headers, etc.). If not, I would recommend asking this question as a separate topic (if the problem is not v9.4.2 of the Acrobat Reader plugin) or on a Chrome/Safari-specific or more general forum (if the versions of those browsers which you need to support are not using the Acrobat Reader plugin).
Has there been any response from Adobe on this? Upgrading to Adobe Reader X isn't an option for us and we have external customers that were once working (9.4.1) and are now broken (9.4.2). Adobe pushed an update via their automatic updater that broke these clients. Does Adobe intend to fix them?
Internally, we are using the MIME\Database Content reg hack mentioned above and have our internal customers working but, I cannot suggest that to my external customers without Adobe's support. Even moreso, I cannot recommend that my external customers upgrade to Reader X.
Adobe - You broke these machines via Auto-updates. Please address the issue.
We have looked into this issue and have been unable to reproduce this in-house, We've created an internal web server that returns the MIME type "application/pdf;charset=UTF-8" for PDFs, and Reader 9.4.2 on all our machines, all our OS versions and IE versions, works just fine with that server.
Do you have a URL and/or login we can use on your site to try to reproduce this?
@BrowserPDFMan - are you Adobe Support? If not, thanks for taking the time to try to repro it.
We are using a 3rd-party web site which I won't mention on this forum. However, if you'd like to try to repro - our URL uses the following charset:
Internally, we are able to get our AR942 users running the streamed PDFs by applying this reg hit (mentioned above in the forum thx to RStoddart)
For obvious reasons, we don't want to have to ask our customers to apply the above reg hack. It would be better to fix the broken AR942.
We found it, after one of those 'Aha' moments turned into a 'D'oh' moment.
If the PDF is served with an extension of ".pdf" it will still work, even if the mime type includes "charset=UTF-8".
If the PDF is served with a different extension (or none), and the mime type has "charset=UTF-8", it will not work. This is also the case with the forms-types files we handle (.fdf, .xfd, .xfdf, .xdp).
This is an important bug that we want to fix and will be in a future release as soon as we can get it into the process (but it takes a while to do the full testing we need to do, so I can't promise it right away).
Unfortunately I cannot find any workaround other than use the .pdf extension, I know that is very frustrating.
This is now part of our regular testing, you can be assured.
Please clarify what you mean by "served with an extension of '.pdf'". Is it:
1. The final file extension-looking portion of the url
2. The extension portion of the filename: in the Content-Disposition http header?
If it is the first option, perhaps this is a good chance to review the reasons for that implementation as well?
My agency started recieving complaints about this problem last Friday.
We have a variety of pdfs that will not download in IE. Firefox and Chrome have no problems with the download. Let me give you some samples:
http://www.scdot.org/doing/bridge/06design_manual.shtml (if you click on the SCDOT Bridge Design Manual link in the first paragraph)
http://www.scdot.org/doing/tenyear.shtml (select any county from the county dropdown, and select GO)
I have numerous other complaints. The Bridge Design Manual has for several years, the ten year content was places on the site within the last few weeks.
The files work fine when downloaded locally.
I have installed version 10.0.1 and this does not correct the problem. IE9 reports the following versions of the adobe add-ons:
Adobe PDF: 184.108.40.206
Adobe PDF Link Helper: 10.0.1.434
Adobe PDF conversion toolbar: 220.127.116.11
SmartSelect Class: 18.104.22.168
Is there a fix for this yet?
I looked at this site and there actually appears to be something wrong with the server. In IE, I clicked "Saved Target As..." for the "SCDOT Bridge Design Manual" and it stalled at about 26KB. When I do this, Reader is not involved at all since it's just IE saving the file locally.
I tried downloading it in IE8 and Firefox 3 and both stalled. I tried this on Firefox 3 macintosh (which Adobe Reader doesn't support) and the same thing happened. Your particular file doesn't appear to be a Reader issue.
Can you check that your server is not getting some sort of error trying to read this file?
Hi. It's not an Adobe problem. It's IE. I use Foxit reader and haven't even got Adobe on the computer and I have the same problem. This isn't an answer to it, just me telling you it's not Adobe or Foxit. I haven't found an answer yet. I will say, however, the examples given to try and open (the scotbridge manual) did open in IE9 for me just now. I think it's some types of PDF or the way they're named (illegal spaces, extra extensions etc).
Hi Guys, recently we have migrated our application from one server to another. After that we are facing issues while accessing a link which opens a PDF in pop up page with print option. Our application is getting used by over than 15000 users and now many users have started complaining that once they are clicking on link, instead of pop page, they are getting "The file that you are downloading cannot be opened by the default program. It is either corrupted or has incorrect file type. As a security precaution, it’s recommended that you cancel the download." message with save and cancel information of the file which should not be the case.
Also many users are getting pop up page but nothing is coming on there and it's all blank. I have noticed that who sover are getting blank page those users are using IE8 or IE9 and those users are getting error message, IE6 or 7 for them.
Please help me guys what I can do, any code change or setting change which I can tell them.