Firefox忽略内容分解

发布于 2025-01-19 12:45:18 字数 839 浏览 3 评论 0原文

我正在尝试编写MVC端点，该端点将选择将内容分解设置为内联或附件，以便在新的浏览器选项卡中显示文件（pdf），或者以下载它。 UI允许用户选择他们希望如何打开文件（不是我的设计 - 无法更改其方面）。

请注意，这可以按预期的方式在Chrome/Edge中起作用。

在Firefox中，PDF的申请设置似乎胜过内容。是否有可靠的方法来尊重firefox？最好是一种可以使用浏览器安装的香草安装的方法，以便最终用户不需要对其进行任何修改才能工作。

这是我用来设置响应的代码（类是从apicontroller派生的）：

var response = Request.CreateResponse(System.Net.HttpStatusCode.OK);
response.Content = new PushStreamContent((stream, content, context) =>
{
    dispatcher.Dispatch(request, stream);
}, new MediaTypeHeaderValue(MediaTypeNames.Application.Pdf));


response.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue(contentDisposition)
{
    FileName = $"{auto_generated_fileName}.pdf",
};

response.Headers.CacheControl = new CacheControlHeaderValue()
{
    NoCache = true,
    NoStore = true
};

return response;

原文

I'm trying to write MVC endpoint that will optionally set the content-disposition to inline or attachment in order to either display the file (a pdf) inside a new browser tab or else to download it. The UI allows the user to select how they'd like to open the file (not my design - can't change that aspect of it).

Note that this works in Chrome/Edge just as expected.

In Firefox, the application settings for PDF appear to trump the content-disposition. Is there a reliable way to get Firefox to respect the content-disposition? Preferably a way that will work w/ a vanilla installation of the browser such that end-users don't need to make any modifications on their end for it to work.

Here's the code I'm using to setup my response (class is derived from ApiController):

var response = Request.CreateResponse(System.Net.HttpStatusCode.OK);
response.Content = new PushStreamContent((stream, content, context) =>
{
    dispatcher.Dispatch(request, stream);
}, new MediaTypeHeaderValue(MediaTypeNames.Application.Pdf));


response.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue(contentDisposition)
{
    FileName = quot;{auto_generated_fileName}.pdf",
};

response.Headers.CacheControl = new CacheControlHeaderValue()
{
    NoCache = true,
    NoStore = true
};

return response;

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

把人绕傻吧 2025-01-26 12:45:18

我们也在WebApp中注意到了这个问题。 WebApp具有一个下载按钮，可让用户下载PDF文件。 Firefox在当前选项卡中显示了PDF文件，该文件有效地杀死了WebApp。

经过一番研究之后，这似乎是一个有意的功能，请参见 firefox 98 的发行说明：

当您设置一个应用程序以打开Firefox偏好设置中特定类型的文件时，这些文件将自动打开，甚至由网站提供的文件“ content-disposition：attactment”。默认情况下，设置为在Firefox中打开的PDF文件也是如此。这是解决 bug 453455 。

就我个人而言，尽管我可以理解某些用户可能想要这个行为不佳的网页，但这是行为良好的Web应用程序的问题。

设置 noreferrer“似乎也无法正常工作，Firefox仍然显示文件内联（使用Firefox 99.0进行测试），

因此据我所知，如果浏览器不允许，您不能强迫浏览器下载文件。其他Web应用程序（例如OwnCloud或Google Drive）也存在相同的问题 - 如果您单击Google Drive中的PDF文件，然后单击dowload，Firefox仍然打开PDF文件，而Chrome则将下载。

目前，您能做的最好的方法是在新标签中打开文件，以防止WebApp或网页被下载的文件替换（这也是Google Drive似乎正在执行的操作）。您可以通过 target属性在＆lt; a＆gt;链接或通过 formtarget atttribute 在＆lt; button＆gt;元素上。

回复收藏 0 原文

尘曦 2025-01-26 12:45:18

在尝试找到与OP相同问题的解决方案后，我找到了 @Blutorange的答案。但是，就在我到达这里之前，我从2013年开始偶然发现了这个答案 - https://stackoverflow.com/a/a/16515146 建议将content-type标题设置为application/Ocket-stream，而不是application/pdf。

我尝试了该解决方案，您知道什么 - 它有效！ PDF会自动在Firefox的新标签中打开，但至少它不能替换我的应用程序的标签，所以！ Chrome似乎也不介意，我在计算机上的PDF查看器也将文件识别为PDF。

现在，这可能不是我们面临的问题最“正确”的修复程序，但这是强迫打开新标签的替代方法。

回复收藏 0 原文