从另一台服务器下载时，HTML5 下载属性不起作用，即使 Access-Control-Allow-Origin 设置为全部 (*)

Question

我有一个像这样的下载链接:

<a href="foo.xls" download="bar.xls">Foobar</a>

这在同一台服务器上下载文件时工作正常，但当从另一台服务器(在本例中为 Azure blob 存储)下载时，文件名保持为“foo.xls”，即使 HTTP 响应返回时带有以下 header :

Access-Control-Allow-Origin: *

这是设计使然，还是我可以将另一个 header 添加到 HTTP 响应以使其正常工作？

Answer 1

是的，根据设计，CORS header 对 download 属性没有影响。只有两种浏览器支持 download 属性，即 Firefox 和 Chrome，并且这两种浏览器对跨源文件的策略不同。

Chrome 版本 prior to 65实际上确实允许跨源文件的 download 属性，没有 CORS header ，但 Firefox 选择不这样做，理由是潜在的社会工程攻击。

MDN 在 download attribute section for the a tag 下记录了 Firefox 20 的这种行为，此后一直没有改变的行为。

In Firefox 20 this attribute is only honored for links to resources with the same-origin.

This Bugzilla report讨论了安全问题和使用 CORS 的可能性。

When the user clicks such a link, the user will be prompted if they want to download. It seems very easy for the user to make the mistake of thinking that something on the original website is being downloaded, and not something from bank.com.

Would it be possible to implement it with same-origin and CORS (Access-Control-Allow-Origin) in mind if you are questioning cross origin security? This is very useful feature for web applications (create Blob using JS and let user download it with some meaningful name)

Google 反对为此使用 CORS。

还有 this Bugzilla report ，总结了他们从其他错误报告中得出的决定。

Also, cross origin downloads are working perfectly in Google Chrome.

是的，我们认为他们这样做是在增加安全漏洞。

Bugzilla 问题似乎不排除将来使用 CORS 进行跨源 download 属性支持的可能性，但现在使用 CORS header 对 下载属性。如果其他浏览器开始支持该属性，则有可能达成共识。

为了完整起见，当然还有 Content-Disposition header ，您可以使用它来强制从其他域下载，但这不提供与 相同的功能下载 属性。不过它确实有更好的浏览器支持。