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

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

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

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

<块引用>

访问控制允许来源:*

这是设计使然，还是有可能我可以将另一个标头添加到 HTTP 响应中以使其正常工作?

解决方案

是的，CORS 标头对 download 属性没有影响是设计使然.只有两种浏览器支持 download 属性，Firefox 和 Chrome，两种浏览器对跨域文件的政策不同.

Chrome 版本 65 之前实际上确实允许跨域文件的 download 属性，没有 CORS 标头，但 Firefox 选择不这样做，理由是潜在的社会工程攻击.

MDN 在 a 标记 的download 属性部分，此后的行为没有改变.

<块引用>

在 Firefox 20 中，此属性仅适用于指向同源资源的链接.

此 Bugzilla 报告讨论了安全问题和使用 CORS 的可能性.

<块引用>

当用户点击此类链接时，系统会提示用户是否想下载.用户似乎很容易犯错认为原始网站上的某些东西正在下载的，而不是从 bank.com 下载的.

<块引用><块引用>

能不能用同源和CORS来实现(Access-Control-Allow-Origin) 如果您质疑跨来源，请记住安全?这对 Web 应用程序非常有用(创建 Blob使用 JS 并让用户用一些有意义的名称下载它)

Google 反对为此使用 CORS.

还有这个 Bugzilla 报告，总结了他们从另一个错误中做出的决定报告.

<块引用><块引用>

此外，跨源下载在 Google Chrome 中也能完美运行.

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

Bugzilla 问题似乎不排除将来使用 CORS 进行跨域 download 属性支持的可能性，但现在使用 CORS 标头对 <代码>下载属性.如果其他浏览器开始支持该属性，则可能尚未达成共识.

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

I have a download link like so:

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

This works fine when downloading a file on the same server, but when downloading from another server (Azure blob storage in this case) the filename stays as "foo.xls", even though the HTTP response comes back with the following header:

Access-Control-Allow-Origin: *

Is this by design or is there potentially another header I can to add to the HTTP response to get this to work?

解决方案

Yes, it is by design that the CORS headers have no affect on the download attribute. There are only two browsers that support the download attribute, Firefox and Chrome, and both browsers have a different policy on cross-origin files.

Chrome versions prior to 65 actually did allow the download attribute on cross-origin files, without CORS headers, but Firefox chose not to, citing potential social-engineering attacks.

MDN documents this behavior for Firefox 20 under the download attribute section for the a tag, behavior that has not changed since.

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

This Bugzilla report discussed the security concerns and the possibility of using 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 was opposed to using CORS for this.

There's also this Bugzilla report, which summarizes their decision from the other bug report.

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

Yes, and we think they're adding security bugs by doing that.

The Bugzilla issues don't seem to rule-out the possibility of using CORS for cross-origin download attribute support in the future, but right now using CORS headers does not do anything for the download attribute. It's possible that if other browsers start supporting the attribute, a consensus may yet be reached.

For sake of completeness, there is of course the Content-Disposition header which you can use to force a download from the other domain, but this does not provide the same functionality as the download attribute. It does have better browser support though.