摘要

  • RFC 9842 允许一份 HTTP 响应在满足同源、URL 模式、请求目的地与新鲜度条件时，成为未来响应的外部压缩字典。
  • 字典哈希、客户端的 Available-Dictionary 声明、服务器的编码选择、缓存变体、解码结果和响应含义必须分别记录；其中任何一项都不能代替最终决定。

压缩字典的吸引力很直接：客户端已经保存了一段字节，服务器就可能用它压缩后来的内容，减少传输量。但“已经保存”极易被说成“已经拥有”。RFC 9842 的真正价值恰在于阻止这种跳跃。客户端拥有的是可能作为压缩输入的一段历史字节，而不是一份后来响应的事实、含义或权利。

第一步由服务器发起。Use-As-Dictionary 可以把某个响应标记为未来请求的候选字典。其 match 成员必须存在，并受到同源 URL Pattern 规则约束；match-dest 可以进一步限制请求目的地；id 和 type 只是边界清楚的附加信息。RFC 特别要求客户端把 id 当作不透明字符串，服务器也不得依靠 id 保证字典内容。标签不是内容证明，更不是授权凭据。

随后是客户端自己的判断。候选字典必须仍然新鲜，或被明确允许以过期状态提供；发出的请求必须满足同源、目的地和 URL 模式条件。多个候选同时匹配时，标准还规定了取舍顺序。这个判断的输出很窄：某个本地字典可以为这一请求被考虑。它没有说明目标资源已经生成，没有说明资源在业务上仍然有效，更没有说明用户可以据此操作。

当客户端决定提供这种能力时，它在 Available-Dictionary 中只发送一个最佳匹配字典的 SHA-256 哈希，并可在 Accept-Encoding 中声明 dcb 或 dcz。这里传递的是受限能力信号。它不迫使服务器使用该字典，也不预先选择服务器将发送的表示。哈希只把一段外部字典字节与压缩流对齐；它没有认证响应的业务含义，也不证明接收者读懂了响应。

服务器拥有独立选择权。它可以使用普通表示、其他编码，或在支持且选择使用客户端所声明字典时返回 Content-Encoding: dcb 或 dcz。两种格式都带有字典哈希，因此可避免以错误字典解压。这个保证不能被扩大为“响应是当前的”“内容获得批准”“价格仍有效”“配置已经生效”或“行动已经完成”。

缓存规则同样只处理一个层面。可缓存的字典压缩响应必须在 Accept-Encoding 和 Available-Dictionary 上使用 Vary，以免不同能力或不同字典的客户端收到错误变体。这是兼容性控制，不是业务状态审计。即使 HTTP 缓存的变体完全正确，应用层权限、外部数据的新鲜度、风险阈值和不可逆行动的条件仍然可能不同。

安全限制也没有消除这个界线。该机制只能在安全上下文中使用，字典与请求须保持同源，必要缓解措施失败时客户端必须丢弃响应。RFC 9842 还警告，公共与私密数据混合压缩可能通过长度或处理时间泄露信息，并要求把字典哈希视为可跟踪状态，采用类似 cookie 的分区和清除原则。HTTPS、同源和哈希都是重要控制，却都不是授权、意图或结果。

compression-dictionary 链接也只是提示：它表示某资源未来可能有助于压缩。客户端决定是否以及何时获取；下载后的资源还要带有 Use-As-Dictionary 和缓存元数据才可使用。链接不证明资源已下载、已匹配、已采用或改变了后续响应。

对领导团队而言，正确的证据链应保持分层：字典 URL 与哈希、保存时间与新鲜度、同源和模式判定、请求目的地、客户端声明、服务器编码选择、缓存变体、解码结果、响应语义以及独立的行动与效果。RFC 9842 使传输更有效率，却不会把这条链压扁成一个结论。

来源