Rob--W
commented
10 years ago First of all, if you want to use PDF.js in a web app, then you can just build PDF.js and put the files on your server. I have just updated the PDF.js wiki for easy instructions, see https://github.com/mozilla/pdf.js/wiki/Setup-PDF.js-in-a-website#wiki-pre-built-pdfjs
About your specific report:
Chrome extensions cannot redirect a request after receiving headers. To work around this limitation, I block the request by appending a header (X-Frame-Options: Deny) to prevent Chrome from performing the default behavior of PDF files, see https://github.com/mozilla/pdf.js/blob/0c268f23453b422b85fb58cfa443e8fbf0309191/extensions/chromium/pdfHandler.js#L148-L159.
Now, the method seems to fail for PDF.js that are loaded using <iframe src="file.pdf"></iframe>. I'll try to find a solution to this problem.
All of these hacks and work-arounds will be obsolete once the Chromium project accepts my patch to support redirections at the onHeadersReceived stage, see https://codereview.chromium.org/154473002/.
PS. Next time, please report bugs at the official PDF.js bug tracker at https://github.com/mozilla/pdf.js/issues.
I decided to use pdf.js in the web app I'm developing. However, I've hit a snag that I can't seem to overcome and I don't know where the problem is.
I am attempting to load PDFs into an iFrame in Chrome but I always get the error "Refused to display '[url]' in a frame because it set 'X-Frame-Options' to 'deny'." Afterwards the pdf opens in a new tab
I have tried writing a PHP script that serves the requested PDF-file with X-Frame-Options set to SAMEORIGIN. I even tried adding this to to my httpd.conf and .htaccess: "Header always append X-Frame-Options SAMEORIGIN"
Reviewing the request that occurs, it clearly says in the HTTP-header section that X-Frame-Options is set to SAMEORIGIN. Chrome still complains.
Since the native pdf-viewer in Chrome (which sucks big time, by the way) has no problem handling the pdfs, I'm wondering if the problem is with the extension. Thoughts?