11

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?

Noah Martin
  • 1,708
  • 9
  • 35
  • 73

2 Answers2

3

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
Simon Cevc
  • 31
  • 3
  • tried it but didn't work – Noah Martin May 09 '22 at 09:39
  • 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. – Lifeweaver Nov 14 '22 at 14:54
-1

I have found that in my environment, URLs containing basic authentication do not allow inline display of pdfs.

  • I would suggest to put this as a comment since it doesn't provide a solution. On the other hand, I have no authentication here, and inline pdf is opened fine. Issue is with the filename showing. – Noah Martin Apr 20 '22 at 07:46