摘要

  • W3C 于 2014 年 3 月 18 日发布子资源完整性首份公开草案，尝试用加密摘要核对取得的文件。早期草案考虑的元素种类，比 2016 年建议书最终规定的范围更广。
  • 2016 年 6 月 23 日的 W3C 建议书为脚本及样式表链接定义了 integrity 元数据。浏览器计算合格响应的摘要；内容与预期不符时，拒绝执行脚本或呈现样式表。

快递员照着熟悉的地址，把包裹送到了网页门口。网址没错，送货时间也没错，里面的东西却可能换了。脚本内容一变，页面行为可能跟着变；样式表一变，读者看到的版面也可能变。地址解决“去哪里拿”，摘要解决“拿到的是哪一份”。网页开始在门口看包裹，而不只看门牌。

2014 年 3 月 18 日的 W3C 首份公开工作草案提出以加密散列值核对下载资源。草案把可能使用完整性元数据的元素列得很广，除了脚本和样式表，还谈到图像、嵌入框架等。那是一张摆满工具的工作台。后来定稿时，留在台面上的工具更少，使用位置也更明确。

到了2015 年 11 月 12 日的候选建议书快照，设计集中在 script 与指向样式表的 link 元素。2016 年 6 月 23 日的 W3C 建议书沿用了这个范围。作者可以在 HTML 中把 integrity 值写在资源地址旁边。浏览器拿到可核对的响应，计算实际内容的摘要，再与作者给出的预期值比较。快递送对了楼，还得送对箱子。

完整性元数据包含散列算法名称和预期摘要。2016 年建议书要求用户代理支持 SHA-256、SHA-384 和 SHA-512；也允许为同一资源给出多个摘要，由受支持的最强算法优先参与检查。这些细节把“我想加载那份文件”变成可执行的条件。外来代码即将运行、外来样式即将进入页面时，浏览器手里已经有了验货单。

验货仍受浏览器的加载规则约束。2016 年文本允许核对同源响应，也允许核对经 CORS 明确开放读取的跨源响应。不透明的跨源响应无法提供检查所需的内容。发布者既要给出预期摘要，也要让资源以可检查的方式到达。完整性校验依赖一条完整的交付路径，而不只是一串醒目的字母。

如果摘要对不上，2016 年建议书要求浏览器拒绝执行或呈现该资源，并按网络错误处理。错误事件使作者有机会提供后备版本，例如自己保存的一份已知文件。熟客带来了陌生包裹，门口先停下来；之后如何继续服务读者，由网页作者安排。

W3C 发布历史把 2014 年首份草案、2015 年候选阶段和 2016 年建议书连成一线。W3C 在 2016 年 6 月 23 日的公告概括了目标：核实取得的资源在送达时没有发生意外改动。几份文件并排看，还能看到范围收敛的过程：早期更长的元素名单，最终落到了脚本和样式表链接。

发布者每天要面对一个实际后果：打算更新脚本时，预期摘要也必须一起更新。旧摘要会拦住新版文件，就像拦住未经预期的改动。作者决定邀请哪一份内容，浏览器负责比对。网址把快递员带到门口，指纹才说明箱子里是否装着订好的东西。