摘要：对于通过去下载文件时跨域的问题有一个解决思路是自己写一个代理服务代理服务负责在服务端下载文件并配置好跨域相关的信息然后请求走代理服务进行下载。
0. 概述
文件下载是web应用中很常见的场景，在浏览器中下载文件, 最基本的方式就是——在页面内隐藏iframe, 然后将文件下载地址加载到iframe中, 从而触发浏览器的下载行为。 此外, html5引入a标签的download属性, 也是一种下载方式。
下载
下面针对下载地址的Response Header、浏览器兼容性, 以及一些特殊case, 做一些说明。
1. 怎样的文件url才能触发浏览器的下载行为?能触发浏览器下载的url有两类:
response header中指定了Content-Disposition为attachment，它表示让浏览器把响应体作为附件下载到本地 (一般Content-Disposition还会指定filename, 下载的文件默认就是filename指定的名字)
response header中指定了Content-Type 为 application/octet-stream(无类型) 或者 application/zip(下载zip包时)以及其它几个不常见类型 (其中还有浏览器差异)，其中 application/octet-stream表示http response为二进制流(没指定明确的type), 需要下载到本地, 由系统决定或者用户手动指定打开方式。
关于application/octet-stream的情况, 补充几点
这种response, 由于没有明确的type, 如果作为文件下载的话, 下载下来的文件将没有文件名和拓展名(文件名直接取的url path的最后一坨)
如果不作为文件下载, 比如已知response body是一张图片, 可以通过img标签来显示图片
下载下来的内容, 只是缺少文件拓展名而已, 文件内容是完整的, 如果知道它实际的拓展名, 手动改了就能通过系统默认的程序打开, 不改拓展名的话也能通过指定应用程序的方式打开
关于response header的Content-Type, 补充几点
首先要明确, Content-Type只是HTTP协议的部分, 不影响response body自身
Content-Type影响的是response的接收方(一般是浏览器), 对于浏览器而言, 它影响的是浏览器对响应体的处理方式. 比如指定为application/zip, 浏览器就会用pdf阅读器打开.
Content-Type之于浏览器, 就好比文件扩展名之于操作系统, 影响的默认行为, 如果你指定了打开方式, 那么Content-Type就不起作用了. 比如, 你在服务端对图片地址设置Content-Type为application/zip，但你在浏览器使用img标签(相当于指定了打开方式)去加载, 照样能正常加载图片。
为什么上面说的「Content-Type」还有「文件拓展名」对于文件自身没有影响?
这里涉及到「文件格式协议」/「文件头」等内容, 待补充...