Chrome sends two requests when downloading a PDF (and cancels one of them)

Question

I noticed that whenever you download a PDF in Chrome, it consistently makes two requests, and then cancels one of them. This is causing the request to be registered twice in my Web app, which don't want. Is there a way to get Chrome to only make one request for PDFs?

I've researched this topic quite a bit now, and I have not found a sufficient answer. Closely-related answers suggest that the problem is that Chrome is looking for a favicon, but the network tab shows that it is actually making the same request twice, and then canceling the second request.

Is there a way to prevent Chrome from making the second request?

Below is a link to a random PDF file that I found through Google which when clicked should demonstrates the behavior. I would've posted a picture of my network tab in devtools but this is my first post on Stack Overflow, and the site is prohibiting me from uploading a picture.

https://www.adobe.com/enterprise/accessibility/pdfs/acro6_pg_ue.pdf

Answer 1

It looks like a bug in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=587709

The problem is that Chrome, when it loads an iframe that returns a PDF stream, writes an "embed" tag inside that iframe which again contains the same URL as the iframe. This triggers a request for that URL again, but Chrome immediately cancels it. (see the network tab) But by that time, the damage is done.

We have the same issue here, and it does not occur in Firefox or IE.

We're still looking for a good solution to this problem.

Answer 2

I'm still trying to find a proper solution but as a partial "fix" for now you could have two options

1) set the content disposition to "attachment" in the header

setting that to "inline" cause chrome to run a second cancelled call

so for example you can do something like that (nodejs resp in example)

res.writeHead(200, {
    'Content-Type' : 'application/pdf',
    'Access-Control-Allow-Origin' : '*',
    'Content-Disposition' : 'attachment; filename=print.pdf'
});

unfortunately this solution will force the browser to download the pdf straight away instead of rendering it inline and that's not maybe desiderable

2) adding "expires" in the headers this solution will always fire a second cancelled call but it's ignored by the server

so for example you can do something like that (nodejs resp in example)

res.writeHead(200, {
    'Content-Type' : 'application/pdf',
    'Access-Control-Allow-Origin' : '*',
    'Content-Disposition' : 'inline; filename=print.pdf',
    'Expires' : new Date(new Date().getTime() + (60000))
});

Answer 3

I had the same problem in an iframe. I turned of the PDF Viewer extension and the problem disappeared. I'm thinking the extension downloads the file twice. The first time to get the size, the second time to download with a progress bar (using the size gathered in the first request)

Answer 4

I've tried the other solutions and none worked for me, I'm a little late, I know, but just for the record, I solved this in the following manner:

Adding the download attribute:

In my case I was using a form, so it goes like this:

<form action="/package.zip" method="POST" download>

This worked on Brave and Safari, which previously showed the same problem, I think it will work for Chrome.

Answer 5

With my case, problem wasn't browser related. I've noticed our scrollbar plugin's (OverlayScrollbars) DOM manipulations reloads embedded pdf data and calls controller more than once due to on plugin's construct or destroy events. After I've initialized scrollbar before DOM is ready, problem is solved.