内容处置内联文件名不起作用

Question

关于这个主题有一些老问题，但我面临的问题只是几天前的问题，所以想创建一个新线程。

我使用内联内容处置与文件名相结合直接在浏览器中打开 PDF 文件。

内容配置：内联；文件名=“我的文件.pdf”

直到几天前，它在 Chrome 和 Firefox 中工作正常（我知道在旧的 IE 版本中，文件名参数不能内联工作），PDF 可以在浏览器中使用正确的（提供的）文件名打开。现在，即使对于 Chrome 和 Firefox，文件名参数似乎也不再起作用了。PDF 已正确打开，但使用 URL 最后部分的名称创建，在我的例子中只是pdf (https://.../ pdf )。

如果我切换到附件而不是内联，文件名工作正常，文件将以正确的文件名下载。问题是我需要在浏览器中打开文件而不是下载它。

在 Chrome 和 Firefox 中，内联文件名不再可能了吗？

Answer 1

我最近面临着非常类似的问题。

奇怪的是，当对 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