关于这个主题有一些老问题，但我面临的问题才刚刚出现几天，所以我想创建一个新的线程。
我使用内容处置内联和文件名直接在浏览器中打开PDF文件。
内容处置：内联；filename＝"；MyFile.pdf"；
直到几天前，它在Chrome和Firefox中运行良好(我知道在旧的IE版本中，filename参数不能在内联中工作(，PDF在浏览器中以正确的(提供的(文件名打开。现在看来，文件名参数甚至在Chrome和Firefox上都不起作用了。PDF被正确打开，但使用URL最后部分的名称创建，在我的情况下，它只是PDF(https://.../pdf(。
如果我切换到附件而不是内联，则文件名工作正常，文件将以正确的文件名下载。问题是我需要在浏览器中打开文件，而不是下载它
在Chrome和Firefox中，内联和文件名是否不再可用？
我最近也遇到了类似的问题。
奇怪的是，当对PDF文档进行POST请求时，文件名被忽略了。但如果我提出GET请求，一切都会像以前一样工作。PDF显示正确，"另存为"也可以使用正确的文件名。
我最终在服务器端进行了重定向，所以最后一个请求是GET。
我注意到的另一件事是，当用户单击浏览器PDF查看器中的下载(另存为(按钮时，服务器会收到另一个文档请求，并再次提供内容。但是，"打印"命令不会发出另一个请求，而是打印PDF查看器中已经存在的内容。
希望这些信息能有所帮助，即使只是让你知道，你不是唯一一个有这个问题的人。
编辑：事实证明，POST和GET请求与该问题无关。问题是Cache-Control: no-store标头阻止浏览器存储PDF内容，并迫使浏览器在"另存为"命令下再次请求PDF内容。POST命令第二次没有正确形成；网络错误"；。我从标题中删除了no-store，现在一切都很好。
新标题如下：
Cache-Control: no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
我发现在我的环境中，包含基本身份验证的URL不允许内联显示pdf。