摘要

  • Content-Digest 核对消息实际承载的内容，Repr-Digest 核对选定表示的完整数据。匹配结果不会识别是谁选择了这些字节。
  • 可用于决策的证据必须分别记录字节域、算法策略、重新计算、签名覆盖、密钥权限、时效、重放判断、业务校验和最终动作。

绿灯说对了一件小事

系统重新计算出的值确实与请求字段一致。错误发生在下一步：它把“字节与摘要一致”扩写成“这份内容可以执行”。前一句是计算结果，后一句需要身份与授权，两者之间没有自动通道。

当提交者能同时提供正文和摘要时，强哈希并不会形成门槛。提交者只需对自己的恶意正文计算摘要。接收端重复同一个运算，当然得到相同结果。

因此，决策日志不应只留下 verified=true。它应写明 content_digest_matched、signature_verified、key_authorized 或 replay_rejected。谓词的宾语，正是证据不能越过的边界。

先决定核对哪一组字节

RFC 9530 用两个清晰的字段替代旧的 Digest 设计。Content-Digest 面向 HTTP 消息实际传递的内容；Repr-Digest 面向整个选定表示数据。

内容编码、范围响应、请求方法和表示元数据都会让两者分开。网关可能核对收到的压缩内容，应用却以为解压后的表示已经获得验证。两个组件都可能如实报告“匹配”，但说的是不同字节。

所以，选择 SHA-256 或 SHA-512 以前，必须先定义业务不变量：需要保持不变的是线上内容，还是经过语义处理的选定表示？核对发生在编码、解码或重建的哪一侧？RFC 9530 废止 RFC 3230，部分原因正是旧标准中的“实例”在实践中被不一致地理解，尤其混淆了消息内容与表示数据。

结构正确不等于可以信任

两个摘要字段都是 Structured Fields 字典。键标识哈希算法，值承载摘要字节序列；一个字典可以放入多个算法，方便算法迁移。

解析成功只说明格式可读。接收方仍须明确哪些算法获准使用、如何处理多个值、什么失败必须终止。IANA 登记表记录算法状态；RFC 9530 建议在多种场景采用 Active 算法，并禁止在可能存在对手的环境使用 Deprecated 算法。

Base64 只是把字节编码成适合传输的文本形式。哈希、编码和签名是三种不同操作。界面上一串看似复杂的字符，不会因此拥有身份权威。

Want-Content-Digest 与 Want-Repr-Digest 也只是偏好提示。对端可以忽略、另选算法或完全不返回摘要，而不构成协议错误。如果应用必须收到摘要，这条要求要由应用策略明示并执行。

签署摘要字段仍需重新计算

HTTP Message Signatures 可以覆盖 Content-Digest、方法、目标和其他被选择的组件。覆盖摘要字段很有价值：声明的摘要值可以与某把经过验证的密钥绑定。

但签名不会自动覆盖整个 HTTP 消息。若 Content-Digest 没有进入签名输入，签名成功对该字段没有结论。即使它已经被覆盖，验证方仍必须针对实际收到的正文重新计算摘要。

设想一个缺陷替换了正文，却保留签名覆盖的摘要字段。字段没有变化，签名可以继续有效；只有独立重算才会发现正文已经不再匹配。反过来，只重算摘要而不验签，任何匿名提交者都可以交付彼此匹配的正文与摘要。

而且，签名有效也不等于操作获准。应用还要判断密钥是否可用于这项动作、必要组件是否全部覆盖、时间参数是否可接受，以及 nonce 或其他规则是否阻止重放。真实的密钥也可能没有这项权限。

尾部字段改变决策时点

RFC 9530 允许摘要出现在首部或尾部。流式发送者可能直到正文结束才算出摘要，因此尾部字段很实用。但接收方也必须等到最后才拥有完整证据。

如果应用一边读取正文一边提交状态，之后才检查尾部，那么失败可能在不可逆动作之后到达。正确做法是先暂存、使用仍可回滚的事务，或等所有检查完成才执行。

HTTP/1.1、HTTP/2 与 HTTP/3 承载尾部字段的方式不同，中间代理和框架也可能丢弃、合并或以不同接口呈现。配置文档不是运行证据。真实生产链路必须证明：最终决策组件能看到该字段，并在校验完成前没有提交动作。

字节没变，证据仍可能过期

缓存对象今天可以与昨天拥有完全相同的字节，摘要也会继续匹配。但 RFC 9111 另行规定新鲜度、重新验证和陈旧响应的使用条件。摘要不能让缓存内容恢复新鲜。

重放也一样。被截获的已签名请求，可以带着完整正文、匹配摘要和有效签名再次到达。只有有效期、nonce、请求标识符或幂等策略才能决定第二次执行是否合法。

语义安全更是另一套账。配置文件可以格式正确却授予危险权限；软件包可以与发布者给出的摘要一致，却包含已知漏洞。完整性只能保存交给哈希的对象，不能批准对象产生的后果。

用反例界定验证结果

第一项测试应主动提交恶意内容和它的正确摘要。摘要检查必须通过，而身份或授权必须拒绝动作。这能立即揭示系统是否懂得绿灯的含义。

随后只改正文的一个字节并保留摘要，再只改摘要并保留正文，两条路径都应在状态变更前失败。再签署一条没有覆盖 Content-Digest 的请求，证明签名不能被冒充为内容保护；然后覆盖该字段但修改正文，证明验签之后仍需重算。

还要测试多个算法、未知算法、过时算法、压缩与解压、范围响应、表示重建，以及通过每种 HTTP 版本和中间代理传送尾部字段。最后重放有效请求，并提供摘要仍然匹配的陈旧缓存对象。每一扇门都应给出自己的结果，不能共用一个“已验证”。