摘要

  • HTML 链接的 download 属性能要求下载并推荐文件名；服务器的 HTTP 响应也能递上一份命名意见。
  • Mozilla 在 2013 年的缺陷记录和 WHATWG 在 2017 年的讨论，留下了跨站下载边界如何被争论的现场。

网页写着“下载报告”，甚至贴心地替文件拟好名字。鼠标一点，浏览器却像收快递的门卫，发现箱子上贴了不止一张面单。发出按钮的网页写了一张，送来内容的服务器可能写了另一张，而真正要把包裹放进本地文件夹的浏览器，得决定哪张可信。一个按钮能把这场小小的权限分配藏得严严实实。

先有服务器的面单。2011 年 6 月的 RFC 6266把 HTTP Content-Disposition 的用法写清楚：attachment让响应进入保存流程，filename给出文件名，filename*还可以承载国际字符。规范同时叮嘱接收方把名字当建议。路径里的目录片段不能借机把文件塞到别处；可执行扩展名也不能被轻率照单全收。这些细节听着像仓库管理员的工作，却是网页内容进入个人电脑时最实在的一道门槛。

后来，网页也拿到了笔。Chromium 的平台功能记录把 a[download]列在 M14。网页作者在链接上写这个属性，就可以表达“请保存这个资源”的意图，还能给它推荐一个本地名字。保存图表、导出文档、把页面里生成的内容变成文件，都因此少绕几步。麻烦在于：按钮经常在甲网站，文件却放在乙网站。甲能不能替乙的内容决定怎样落到用户硬盘上？

Mozilla 2013 年的一张缺陷单把疑问变成了可点击的例子。同样是指向外站图片、带 download="filename.png" 的链接，报告者看到 Firefox 打开图片，Chrome 下载图片，于是希望两者一致。Mozilla 的回复把 Firefox 的做法称为必要的安全措施，并关闭了缺陷单。用户看到的是同一个链接；浏览器看到的是两个不同来源在同一个文件上发号施令。

到 2017 年 4 月，WHATWG 讨论把分歧讲得更细。讨论记录当时 Firefox 和 Safari 在该跨站情形下忽略 download；Chrome 则会下载，但忽略网页建议的文件名。规范编辑者指出，当时的算法容许这两种结果，并希望实现者趋于一致。原来“下载它”和“把它叫这个名字”可以拆开裁决。同年，WebKit 宣布 Safari 10.1 支持链接的下载属性，还提到从页面创建的 Blob 保存为文件。这是一项值得提供的便利，边界却需要慢慢划清。

现行 HTML 标准把几支笔的顺序摆在桌上：download表达网页的意图，属性值推荐名字；服务器通过 Content-Disposition送来的名字可能覆盖它。跨来源下载需要资源服务器以 attachment作出明确响应，避免一个网页悄悄让别站内容以文件形式到达用户。浏览器最终还要处理危险路径、扩展名和保存位置。

所以，“下载报告”从来不是一句就能执行到底的命令。网页管按钮，服务器管送来的内容，浏览器管本地落点。那个看上去不起眼的文件名，刚好记录了三者在哪里交接权力。文件夹里的名字像结果，背后其实是一份签过三次字的收货单。