pipwerks / PDFObject

A lightweight JavaScript utility for dynamically embedding PDFs in HTML documents.
http://pdfobject.com/
Other
2.39k stars 985 forks source link

PDF URL with query string not working #63

Closed huan086 closed 8 years ago

huan086 commented 8 years ago

My PDF URL is in the form http://server.com/file?id=123&otherstuff=abc

To make it work,

  1. Under generatePDFJSiframe, I had to change to var querystring = PDFJS_URL + "?file=" + encodeURIComponent(url);
  2. Under embed, I had to change to url = url + buildQueryString(pdfOpenParams);
kolin1979 commented 8 years ago

I am having a similar issue as @huan086 . My PDF url is in the form of var link = '/FileDownload.ashx?defid=100&type=1&pre=1&n=BB10&31232132433';

when using PDFObject.embed(link, '#pdfobject-holder'); nothing happens other than getting the Black cross in the top left (enable enhanced security is disabled in Acrobat and the domain is a trusted domain). The embed element is created, the src attribute is correctly populated but it never gets called. (from viewing network monitor in debug tools) putting the contents of the link variable directly into an address bar works. (this is in IE10 64bit)

The fix above didn't work for me. Populating the src of an iframe with the same address works.

IE 10 64bit Acrobat Reader DC

pipwerks commented 8 years ago

Doh. Querystrings in the PDF's URL, I should have included those in the original use cases. Thanks for the reminder.

kolin1979, can you confirm that your ashx file works when embedded using pure markup (no JS)? I'm wondering if the ashx is being served with the PDF MIME type. If not, it may not work regardless of PDFObject.

I have sample code you can copy and paste here: http://pdfobject.com/static.html

kolin1979 commented 8 years ago

@pipwerks the code snippet used to send the mimetype back is (vb.net)

context.Response.AddHeader("Content-length", ms.ToArray.Length.ToString()) context.Response.ContentType = "application/pdf" context.Response.AppendHeader("Expires", "0") context.Response.AppendHeader("Cache-Control","must-revalidate, post-check=0, pre-check=0") context.Response.AppendHeader("Pragma", "public") context.Response.AppendHeader("Accept-Ranges", "bytes") If inline Then context.Response.AppendHeader("content-disposition", "inline;") Else context.Response.AppendHeader("content-disposition", "attachment; filename=""" & filename & """") End If

I've tried sending it back both as an attachment and inline, and still getting the annoying blackbox and cross in the top left.

The following script works in IE11 `

` with this embed code created by pdfobject : `` with the following response headers `Response HTTP/1.1 200 OK Cache-Control must-revalidate, post-check=0, pre-check=0,Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0 Pragma public Content-Length 82041 Content-Type application/pdf Expires 0 Accept-Ranges bytes Server Microsoft-IIS/7.5 content-disposition inline; X-AspNet-Version 2.0.50727 Date Wed, 13 Apr 2016 07:32:26 GMT` Running in IE10/9/8 I get the black box, and the following embed is created : `` no request is made to the URL the PDF reader is Acrobat DC (2015.010.20056) IE is 11.0.9600.18230 I should also point out that IE8/9/10 are tested by changing the Document mode in IE11 developer tools and are not test on vanilla installs. some more debugging info (IE10/Edge) isIE:true supportsPDFActiveX:true supportsPDFs:true A direct html embed in IE10 gives me the same black box an embed within an object works (or at least the object works)
huan086 commented 8 years ago

BTW, encodeURI shouldn't be used without the fix mentioned here: http://stackoverflow.com/a/9247370

pipwerks commented 8 years ago

kolin, I am unable to replicate that issue. I have a test case using PHP to serve the PDF, much like you did with ASP.Net, and it works fine (Chrome, Firefox, Safari, IE9-11, Edge). http://pdfobject.com/examples/querystring-URL-with-params.html

This may be an Adobe Reader and/or IE bug. FWIW, I tested using virtual machines, not document mode. Perhaps changing IE's document mode is causing the issue?

pipwerks commented 8 years ago

huan, I refactored the querystring handling, esp. with regards to "forced PDF.js mode", see: http://pdfobject.com/examples/querystring-URL.html http://pdfobject.com/examples/querystring-URL-with-params.html http://pdfobject.com/examples/pdfjs-forced-with-querystring.html

As part of this refactoring, I updated the encodeURIComponent handling. I had already removed encodeURI, so the fix in that StackOverflow post is not necessary.

kolin1979 commented 8 years ago

@pipwerks I can confirm that switching the document mode was the issue at hand here, (not the querystring as I originally thought) using Microsoft Virtual PC with IE8/IE9/IE10 win7 images, this worked. Must be another quirk of switching document mode. Sorry for the red herring!