electron-pdf-window
electron-pdf-window copied to clipboard
gerhardberger
Can't load a PDF if the URL has parameters
If I pass a URL that ends with ".pdf" to the loadURL method, it works just fine. But I need to invoke a URL like this:
http://server/controller/action?id=1234&type=something
That URL returns a PDF file automatically generated. If I put that address in a Chrome window it loads the PDF without problem. But with the electron-pdf-window it doesn't. It throws an "Unexpected server response" exception. Then I check the console and I can see it is trying to open the following url:
http://server/controller/action?id
That is not the URL I'm invoking. Where is the url being interrupted? I'm looking for it in the code. I know I can find it sometime, but a little help would be very nice. Thank you anyway for a great plugin.
I am having the same problem and need to be able to open pdfs that are returned dynamically from a server call (rather than just a static pdf hosted on a server).
I am having the same issue. What would you need from me to help debug this issue?
A little more information that I can add is that when I add in url parameters to the working pdf URL, the file-type library sees the header as starting with < and not % (ascii 0x3C not 0x25).
That makes me think that it is seeing an XML or HTML style return, but I do not see that when I am using Fiddler to sniff the actual return body.
An update, I translated the start of the buffer when using URL parameters and got this:
<!DOCTYPE html>
<html lang="en">
<head>
<!-- Meta tags -->
<meta charset="utf-8">
<!-- Neces
So some part of the process is returning that instead of directly returning the PDF body that is returned.
I've dug into this issue more, and I have found a fix. However, it ends up reversing part of the last commit.
https://github.com/gerhardberger/electron-pdf-window/commit/71f5d98491e824ec20edbd78f268d795008a4871#diff-168726dbe96b3ce427e7fedce31bb0bc
In order for the URL parameters to be passed correctly, the url must be encoded using encodeURIComponent, but in the last commit it was changed to decodeURIComponent. I didn't see any comments in the commit for why the change was made.
@gerhardberger Can you shed some light on why the encoding was changed from encode to decode?
This bug still has not been fixed. I need to have "=" in my url string but whenever I do that, it only loads the url string up till the "=" and just cuts off the rest.
sorry for the late response, I fixed the url type checking as of 1.0.12, now it can load urls with query params.
let me know if the issue is resolved for you, then we can close this.
It is still doing the same thing as before. :(
This bug still has not been fixed. I need to have "=" in my url string but whenever I do that, it only loads the url string up till the "=" and just cuts off the rest.
Here is a sample filename that I am using:
USP-CUST017185_KGLT3_H=18_SF0.pdf
And this is what is returned to me:
USP-CUST017185_KGLT3_H
Hope that helps you fix the bug
However, using 1.0.10 works for me. Thanks @vandermore for that idea.
Thanks for the package.
FYI, issue still isn't fixed. Had to fork then revert 1.0.11 to make it work.
Problem is that eventually this is what is opened: viewer.html?file=http://example.com/x.pdf?mandatoryToken=a234&id=789 So in loadURL(), encodeURIComponent (not decode) needs to be used otherwise the file url's parameters aren't going to be interpreted as part of "file" above. The test added to 1.0.12 passes anyway probably because that PDF loads whether the added parameters are present or not.
I use 1.0.11,still get the same problem. using 1.0.10 is ok for me. Thanks @vandermore .
** @offg777** - Thank you very much for this (3 years ago). I have been trying to generate, view, and print PDFs in Electron for a while, and this module, with your edits, finally made it work.
