A problem with the download of a pdf file

[Roby73]

Hello everyone and congratulations for the useful plugin!

I have an issue with the download of a pdf file. I did several tests, I finally summed up in test3.html file contained in the archive that I have submitted, in attachment (I know it is not very good... I packed the entire test environment, in a file archive, so after this, I changed its name to get it accepted by the site. So you must save it locally and then rename it as zip file! in the extracted dir, you will find all I have used in the test.). PS. in the fileDownload.js file, I changed the return error function, so to obtain more useful information about the error... but so far still have not managed to solve the problem. My enviroment is Windows XP (SP3), IE8, FF22, Chrome rel 35.0.1916.114 m. I tried also the jQuery 1.10.2 (in the dir).

Thank you for your valuable help. If I find a solution before your reply, I'll let you know. Again, thank you. R.A.

Save and rename to .zip. SHA1: 1e081701ffb2a8d07eaf9c387514277ec1a5fd4f MD5: f6fd3fb728c49af918c12ee6a21bf631

[MaffooBristol]

:+1: I have the same problem!

Chrome: 35.0.1916.153 (Official Build 274914) Linux Ubuntu: 13.04 (Raring)

[MaffooBristol]

I'm wondering whether it's anything to do with the MIME type supplied. When I try and use it with a PDF I get a warning in chrome: Resource interpreted as Document but transferred with MIME type application/pdf

I guess Chrome is trying to render it itself rather than downloading it like it would with other file formats (for example it works fine with CSV, Docx, XLS etc etc), so perhaps the issue isn't related to fileDownload at all. ~~But then why is everything that is being supplied as a specific MIME type (such as application/pdf) being forced to download as a generic "Document" type? Maybe we should investigate whether sending the file as application/pdf will work,~~* or even spoofing it to send it as application/octet-stream or similar if a PDF is supplied?

(* I now realise that the "interpreted as Document" thing is probably just a red herring...)

Looking at this thread on productforums.google.com suggests the only way is to change settings in Chrome itself/install extensions. Same with this SuperUser thread. However here someone says that you can force download by sending it as octet-stream, so it's worth a punt.

I'll have a play with the code and see if I can get anything out of it, will do a PR if it works.

Cheers! Matt

Edit: I realised that if I created a rule in .htaccess to map PDFs to octet-stream, the download works perfectly. It's just a case of whether it's possible to define this instead with fileDownload's "iframe + form" method of downloading it. If you can, I'd suggest modifying your .htaccess or equivalent for now, @Roby73

Here's what I added- obviously this will affect every PDF on the server so perhaps make the regex more specific if need-be:

<FilesMatch "\.(?i:pdf)$">
  ForceType application/octet-stream
  Header set Content-Disposition attachment
</FilesMatch>

Edit again:

Seems impossible, unfortunately. You'll have to manipulate the server: http://stackoverflow.com/questions/1153010/force-mime-type-in-browser-with-javascript

[johnculviner]

I'll take a look at this soon. As a rule of thumb if you are downloading a filetype that a webbrowser can natively handle (EX: images, PDFs etc.) then you must do octetstream on the server to avoid having the browsers native behavior take over which is not what you want going on in the IFRAME that jqfd creates. Thoughts?

[andrereitz]

I have the same problem, it won't dowload even with octetstream. In resources it appears as cancealled

[johnculviner]

The demo page is working still with latest chrome for me (other than yielding the aforementioned info message in the console). I would say just make sure you are writing the response that way

http://jqueryfiledownload.apphb.com/

it's doing this and working fine:

Cache-Control:private
Connection:keep-alive
Content-Disposition:attachment; filename=Report0.pdf
Content-Length:149851
Content-Type:application/pdf
Date:Wed, 10 Jun 2015 04:17:49 GMT
Server:nginx
Set-Cookie:fileDownload=true; path=/

Or am I missing something with another version of chrome?

[andrereitz]

Hi, thanks for your fast reply. You are right, the plugin is working fine. I was too many hours on this and had moved everything to php processing.

Now I got the code back to the plugin and decided to set the cookie via PHP. And everything works!!!

Thank you for the amazing plugin!

[azzimuth]

Hi. I have a similar problem. I use fileDownload to downlad Excel files from a ASP.NET website. In my backend code I have:

return File(filestream, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "filename.xlsx");

and in my JavaScript:

$.fileDownload("DownloadSpecialReport",
    {
      preparingMessageHtml: "<h3>Preparing download...</h3>",
      failMessageHtml: "Something went wrong...",
      httpMethod: "POST",
      data: "countryId=@countryId"
    });

When I check the HTTP response from server I see that the headers have correct values:

content-disposition:attachment; filename=filename.xlsx
content-length:3833
content-type:application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

When the file is being downloaded, I see the Preparing download... dialog, the file is downloaded correctly but Chrome complains in console jquery.1.7.1.min.js:3 Resource interpreted as Document but transferred with MIME type application/vnd.openxmlformats-officedocument.spreadsheetml.sheet and the dialog is never been closed. I tested on Chrome 51.0.2704.103 and IE 11. Any ideas what this can be caused by?

[tynorton]

I am seeing the exact same issue as @azzimuth. Any thoughts?

[johnculviner]

Not sure, do things like the demo and you'll probably be good im thinking (unless that is broken for you?)

[kpyrdol]

I had a similar problem with PDF. My xsls was downloaded correctly. Check if you have in headers: Set-Cookie:fileDownload=true; path=/ Content-Disposition:attachment;filename=XXXXX.EXTENSION