摘要

  • RFC 9659 要求 HTTP zstd 解码器支持不超过且包括 8 MB 的窗口，并禁止编码器生成需要更大窗口的帧。
  • 当前编码器配置、正确的 Content-Encoding 与一次成功抽测，都不能证明旧缓存对象或中间重编码后的实际字节仍符合该边界。
  • 可审计的交付链必须把帧头、对象哈希、缓存代际、变换记录、接收端有效预算、解码结果和应用接受连接起来。

新版本编码器已经把窗口上限改成 8 MB，构建检查也逐帧通过。运维面板因此显示“策略已部署”。但某个边缘节点仍可能持有修改前生成的压缩对象；它没有过期，也没有被精确命中的清理规则删除。用户请求相同 URL，收到的却是另一代字节。配置是真的，检查也是真的，交付仍可能失败。

RFC 9659 解决的正是生产者与接收者之间曾经存在的规范缝隙。对于 HTTP zstd 内容编码，解码器必须支持到 8 MB（含）的 Window_Size，编码器不得生成要求超过 8 MB 窗口的帧。这是一条双向承诺：发送方不能把更大的内存要求推给接收者，声明支持该编码的接收者也不能把共同线任意降到 8 MB 以下。

窗口是帧的属性，不是功能开关

RFC 8878 定义 Zstandard 格式。窗口决定反向引用能够跨越的最大距离，因此影响解码时需要保留的历史内容。格式允许的范围从 1 KB 到约 3.75 TB。更大的窗口可能提高压缩率，却把内存负担带到接收端。

RFC 8878 原先建议 HTTP 解码器支持 8 MB，也建议编码器不要超过 8 MB，但没有把它写成强制要求。于是，编码器可能把大窗口视为合法优化，浏览器或受限代理则可能为保护内存而拒绝；两边都能解释自己的行为，结果却无法互操作。RFC 9659 把建议变成可验证的边界。规范文本 与 XML 源文件 保留了同一条简洁规则。

RFC Editor 信息页 表明它是 IETF 发布的 Informational RFC，并更新 RFC 8878。勘误查询 与 Datatracker 历史 则给内部政策一个可追溯的公共版本坐标。组织不能只说“按 9659”，还应能说清所依据文本及其勘误状态。

协商只决定候选表示，不证明解码

RFC 9110 规定 HTTP 内容编码的语义。Accept-Encoding: zstd 表示接收者愿意接受这种编码，Content-Encoding: zstd 表示所选表示应用了该编码。二者都不携带 Zstandard 窗口值，也不证明是哪一个程序生成了帧、中间层是否重新压缩、进程实际给了解码器多少内存，或者应用是否接受了解码后的内容。

因此，“zstd 响应比例”不是互操作成功率。服务器可以在写出主体前记录选择；边缘可以在客户端开始解码前记录 200；一次小对象请求可能从未接近窗口边界；同一个客户端产品在不同嵌入环境中也可能拥有不同预算。协议标签属于命名层，解码成功属于运行状态层。

RFC 7694 从请求内容方向讨论客户端发起的内容编码与可接受编码。它同样说明能力声明、具体编码字节和处理结果不是一件事。无论请求还是响应，都应分别保留“提供什么、选择什么、实际是什么、结果如何”。

缓存保存了控制面已经忘记的旧决定

RFC 9111 让缓存成为 HTTP 交付语义的一部分。若表示随 Accept-Encoding 变化，缓存键、变体选择和验证就必须保持一致。编码器修正并不会自动改写已经存储的对象。不同边缘可能保留不同代际；一次清理可能只覆盖部分键空间；回退表示若没有独立身份，还可能与原变体混淆。

所以，审计对象不是抽象的 URL，也不是“当前源站设置”，而是实际交付的那组字节。回执至少应包括对象哈希、变体键、生成代次、年龄、清理记录、经过的变换、帧头解析结果与接收端类别。源站新对象正确而边缘旧对象错误时，两个事实必须并存，不能被一个总绿灯覆盖。

IANA HTTP 参数登记表 已把 zstd 描述为 Window_Size 不超过 8 MB 的 Zstandard 字节流。登记表维护公共名称的含义，却不会巡视缓存。登记项给接收者合理预期；实际帧决定生产系统是否兑现。

库能力不等于进程的有效预算

某个解码库可以在测试中支持 8 MB，而调用它的进程可能设置更低限额、同时承受别的工作负载，或在内存压力下分配失败。解码也可能完成，随后解析、校验或业务处理失败。“支持 zstd”必须带上主体、版本、配置、时刻与结果。

接收端证据应拆成三层：库或用户代理宣称的能力，处理该请求时的有效资源限额，以及对已捕获表示的实际结果。错误还要分类为窗口超限、截断、损坏、未知编码、内存不足、字典不匹配或应用拒绝。RFC 9659 明确提醒解码器仍会收到不符合上限的帧，并可对其失败。支持到 8 MB 不意味着为非法输入无限分配。

不要把 dcz 的规则借给 zstd

RFC 9842 后来定义压缩字典传输及 dcz 内容编码。其 Zstandard 窗口规则可以随字典大小变化，上限可能到 128 MB。这是另一种编码、另一套协商与另一条边界。它没有把普通 zstd 的 RFC 9659 上限提高。

风险来自共享实现：同一压缩库、同一配置面板可能只显示一个“窗口”参数，却隐藏内容编码与字典上下文。证据必须保留 token、字典身份和帧类别。内部抽象可以复用代码，不能抹平外部合同。

从生成帧到应用接受

生产端应保留编码器版本、有效配置、编码选择、对象哈希与帧头。每个中间层应记录是原样传递、解码、重编码还是替换。缓存应记录变体键、代际、新鲜度与失效历史。接收端应记录版本、有效预算、观察到的窗口、解码结果及错误。应用层应记录接受，而不是从传输完成推断接受。

抽样可以降低成本，但必须覆盖边界：大对象、旧代际、多地区边缘、受限客户端、回滚、回退和键规则变更。观察到超过 8 MB 的帧、没有变换记录却出现哈希差异、上限修改后仍命中旧对象、协商数与应用完成数发生偏离，都应触发调查。

Heng Lu 的最小初始规范提供合适制度形态：共同线只保留 8 MB 边界与明确失败语义，边界以内允许本地优化。现实分层阻止 zstd 标签窃取成功解码的权威；运行代码优先则把最终判断交还给实际交付的帧与实际执行的接收端。

RFC 9659 让双方知道共同线在哪里。只有对象级证据能说明生产系统是否仍站在线内。

来源