type=pdf not actually returning a PDF and hanging

[zenato]

type=pdf not actually returning a PDF and hanging

[zenato]

@nkuehn Thanks for your issue report.

I tested shell with curl command.

curl -o test.pdf http://localhost:3000/\?url\=google.co.kr\&type\=pdf

It works.

And it worked well on the Chrome browser.

In addition, I added content-length into response header

[nkuehn]

wow, that was fast. Looks like I primarily forgot to properly encode the URL.

but the content-length seems to have an issue in Firefox - curl finishes fine, but when I enter "http://localhost:3000/?url=google.co.kr&type=pdf" in chrome the download is stuck at "128kb of 135kb". The file curl wrote has 137954 bytes which is the "135kb" Firefox is showing.

If I look into the downloads folder the .part file Firefox writes into is already there completely and has the full 135kb that contain a valid PDF I can open. But it's just not completing the process.

Chrome and Safari both happily display the PDF, but not Firefox. Can't really tell why though. I don't think it requires a Content-Disposition header (that would just help being able to control the filename that is saved on disk as far as I know).

Here's somebody with a similarly sounding problem but no real learning: https://stackoverflow.com/questions/34684919/how-do-i-get-firefox-to-complete-a-download-sent-from-restify-nodejs

[zenato]

I tested again via curl, chrome, firefox.
It worked well.

.part file was not created in download directory, and file size was the same as the size specified in the header.
So it seems to be firefox browser issue.

Thanks for your comment.

[nkuehn]

thanks for testing again - I'll dig into what could be the difference on my machine myself then.

[nkuehn]

PS: I got firefox to behave reliable by setting the content-disposition header to make it a download and set the PDF filename. It has an effect on chrome, too - will download then instead of directly showing the PDF. I'll send a PR in case you're interested in changing to that behavior