13

I have a PDF file stored on my server. I am unable to access the file using Google Chrome (or Ubuntu Chromium) via URL "sitename/pdfName.pdf"; while I am able to access the same PDF in Internet Explorer or FireFox without a problem.

Chrome is giving this error: "Failed to load PDF document"

Find attaching the error in this link Error Image.

MeSo2
  • 450
  • 1
  • 7
  • 18
Sumit Dobhal
  • 141
  • 1
  • 1
  • 9

4 Answers4

4

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...

user2728841
  • 1,333
  • 17
  • 32
2

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%<e2><e3><cf><d3>^M

Fixed PDF file:

%PDF-1.6^M
%<e2><e3><cf><d3>^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.

  • 2
    *"it's not completely clear to me if the ^M is a valid line separator."* - according to the specification: *The CARRIAGE RETURN (0Dh) and LINE FEED (0Ah) characters, also called newline characters, shall be treated as end-of-line (EOL) markers. The combination of a CARRIAGE RETURN followed immediately by a LINE FEED shall be treated as one EOL marker.* (ISO 32000-1 section 7.2.2) Your ^M represents a CARRIAGE RETURN (0Dh). So yes, the ^M is a valid line separator. – mkl Oct 09 '20 at 11:37
0

This might be due to Chrome’s built-in PDF Viewer not being able to open Firmex’s protected PDF document.

Try:

  1. Opening Google Chrome (obviously)
  2. In the top right, click More Untitled.png, then Settings.
  3. At the bottom, click Show Advanced Settings.
  4. Under Privacy, click Content Settings
  5. Under PDF Documents, check the box next to "Open PDF files in the default PDF viewer application."
  6. Once you have made the change, PDF files should open in Adobe Reader or Adobe Acrobat, rather than in Google Chrome.

Although it may not be ideal, it's a good alternative for now.

liam
  • 1,918
  • 3
  • 22
  • 28
  • Thanks for your reply!! I have tried the same. But the problem is if I am trying to open the same pdf (in Chrome ) from another sever it's not giving me any error. So for some particular server only this error is coming. – Sumit Dobhal Aug 02 '17 at 17:42
  • That is really weird. Are there any obvious differences between them? – liam Aug 02 '17 at 18:00
0

I had the same problem. In IIS I had to add this web.config file to my PDF folder to get it to work

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <remove name="Content-Type" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

You may also find that Chrome (on Ubuntu 19.04) has a problem with the header of the name: Content-Type value: charset=utf-8.

MeSo2
  • 450
  • 1
  • 7
  • 18