Content-disposition inline filename not working

Question

There are some old questions regarding this topic, but the issue I'm facing is just some days old so thought to create a new thread.

I am using the content-disposition inline combined with filename to open a PDF file directly in Browser.

content-disposition: inline; filename="MyFile.pdf"

Until a couple of days ago it was working fine in Chrome and Firefox, (I know that in old IE versions the filename parameter wouldn't work in inline), PDF was opening in browser with the correct (provided) filename. Now it seems like the filename parameter isn't working anymore even for Chrome and Firefox. The PDF is opened correctly but created with a name from the last part of the URL, which in my case is just pdf (https://.../pdf).

If I switch to attachment instead of inline the filename works fine, file gets downloaded with the correct filename. Issue is that I need to open the file in browser and not download it.

Is inline with filename not anymore possible in Chrome and Firefox?

Bankrupt

Hey Noah, did you. manage to figure this out? Currently facing something similar. – Arteritis

I'm facing this issue myself now. Anybody has any information about this? – Bihari

I found the solution to my problem, it was the Content-Type (MIME type): superuser.com/a/515622/100806 - if it's application/octet-stream, it will always download. – Bihari

Answer 1

I am facing very similar problem lately.

Strangely, when making a POST request for PDF document, the filename is ignored. But if I make a GET request, everything works like before. PDF is shown correctly and SaveAs also works with correct filename.

I ended up making a redirect on the server side, so the last request is a GET.

Another thing I noticed is, when the user clicks on the Download (Save As) button in the browser's PDF viewer, the server gets another request for the document and serves the content again. The Print command however does not make another request and prints the content already in the PDF viewer.

Hope this info helps, even if only to let you know, you're not the only one with this problem.

Edit: It turned out, that POST and GET requests did not have anything to do with the problem. The problem was Cache-Control: no-store header that prevented the browser to store the PDF content and forced it to make another request for the PDF content at Save As command. The POST command was not formed correctly the second time which resulted in "Network Error". I removed no-store from the header and now everything works fine.

The new header looks like this:

Cache-Control: no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0

Ribwort

tried it but didn't work – Bankrupt

I found that the Cache-Control didn't have much effect on this issue for me. My issues were related to the URL. i.e. document/get doesn't work but document/get?id=1 does. Chrome also ignored the filename in Content-Disposition. – Tunisia

Answer 2

This worked for me, only tested with Chrome.
d is a string with the file name, mime type, and server path location

    var loc = d.toString('utf8').split(',') 
    var myFile = createReadStream(loc[2])
    var stat = statSync(loc[2])
    res.setHeader('Content-Length',stat.size)
    res.setHeader('Content-Type',loc[1])
    res.setHeader('Content-Disposition',`inline: filename=${loc[0]}`)
    res.set('Cache-Control', 'no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0');
    myFile.pipe(res)

Wooer