We had object:none in our security policy inside web.config, that was causing chrome to refuse to open it, and pressing f12 in chrome and then click “console” shows the error message.
Changing web.config security policy to object:self fixed the problem
In our case we could open PDFs in firefox and IE but not in Chrome, so Chrome has a stricter implementation of the security policies.
The below is a suggested edit which I have not tested:
You may also find that Chrome has a problem with the header of the name: Content-Type value: charset=utf-8. Removing it may fix it.
Also, as you are testing this, make sure that cache is not interfering with the response by keep on changing the request URL to something new sitename/pdfName.pdf?val=1 and then with the next test, ?val=2 and so on…
When we encountered this problem, the only difference between PDF files that did and did not work was in the fist line of the PDF document itself.
Here’s the difference between the old PDF that caused the error and the fixed version as seen in a binary-enabled text-editor (in this case vim -b):
Original PDF file:
%PDF-1.6^M%
Fixed PDF file:
%PDF-1.6^M
%
So the problem was solved at the source, no need to burden the victims with installing extra software or reinstalling chrome.
I don’t know if this is a problem with the PDF generator, or with the chrome plugin.
According to the PDF specification the first line of a PDF document has to contain the PDF version, but it’s not completely clear to me if the ^M is a valid line separator.