摘要

  • ieof 表示封装正文的真实结尾已经落在预览范围内；服务此时不得再用 100 Continue 要求余下正文。
  • 这项线级事实不能替代内容安全、源站接受、接收者交付或应用成功的证明，但它能精确限定服务究竟看到了完整正文还是一个前缀。

代理正在从源站读取一个事先不知道长度的响应。正文尚未凑满 ICAP 服务允许的预览额度，源站已经关闭输入。客户端把 ieof 加在最后一个预览分块上，告诉适配服务：这不是暂停，而是终点。

如果监控系统只保留适配引擎收到的净荷，ieof 会消失。RFC 3507 要求服务在把数据交给应用逻辑前去掉这个扩展。引擎因此可以拥有完整对象，却不再携带“为何完整”的线级证据。

RFC 3507 于 2003 年 4 月以信息类文档发布，记录当时已经使用的 Internet Content Adaptation Protocol。ICAP 是独立的 TCP 协议；它借用了 HTTP 的表达形式并封装 HTTP 报文，但既不是 HTTP，也不在 HTTP 之上运行。IESG 同时提醒，它早于 RFC 3238 对 OPES 架构与政策问题的讨论，不能单独承担授权与治理。

预览的停点可以落在正文中间

客户端发送全部封装头部，再发送不超过服务通过 OPTIONS 声明的预览正文长度。随后它结束预览分块，等待服务决定返回改写结果、204 No Content，还是在确有余量时返回 100 Continue。

这个暂停点与 HTTP 里常见的头部/正文边界不同。ICAP 已经可能收到若干正文分块。证据至少要包括 ICAP 资源 URI、REQMOD 或 RESPMOD、声明与实际预览长度、封装偏移、分块边界、源站读取状态和首个未发送字节。

规范曾要求客户端具备至少 4096 字节预览能力，但这不是内容分类的充分长度。决定性字段可以位于第 4097 字节，也可以跨越分块。把历史互操作下限写成“已检查全文”的门槛，会把带宽优化变成不存在的保证。

ieof 把暂停改写为终点

当代理无法预知源站会给多少数据，而源站又在预览阶段结束时，最后一个预览分块携带 ieof。服务由此知道：它收到的不只是允许范围内的前缀，而是这一正文的实际末尾。

此时 100 Continue 被禁止，因为没有剩余正文可供发送。服务可以返回适配后的消息，或在条件允许时返回 204。这是一条可测试的不变量：同一事务里一旦出现有效 ieof，随后就不应出现索取余下正文的 100。

然而 ieof 并不证明内容无害、格式有效或接收者会接受。它只证明客户端在该观察点声明输入已经结束。上游若撒谎、截断或故障，完整性仍需另一套来源和长度证据。

没有 ieof 也不承诺还有字节

反方向的推论同样危险。预览中没有 ieof，只说明客户端没有在那个终止块上声明正文结束。源站可能稍后断开，连接可能失败，或剩余数据可能因流控永远无法抵达。

服务返回 100 后，客户端应从预览之后的第一个分块继续。若没有数据到达，记录应显示未完成输入，而不是把“获准继续”算成“全文已处理”。

因此，预览终点、连接终点和语义正文终点是三个字段。可靠审计保留它们的时间和字节位置，而不是压缩成一个 completed 布尔值。

204 依赖客户端保存原文

在预览事务里，204 No Content 允许客户端按原消息未被修改来继续。省下重传，是因为客户端已经缓存预览部分，并仍然持有或转发余下内容。

预览之外，客户端只有发送 Allow: 204，才明确承担保留足够原文字节的责任。没有这项许可，服务若不修改消息，也必须返回完整的相同消息，而不能只发一个空的 204。

所以 204 描述的是重建合同：谁保存字节，谁承担内存、回压与失败恢复。它不等于“干净”“已认证”或“政策允许”。规范甚至容纳服务不愿或不能修改的情况。

REQMOD 的 HTTP 错误不一定来自源站

请求修改模式可以产生改写后的 HTTP 请求、一个封装的 HTTP 错误响应、允许条件下的 204，或者 ICAP 层错误。若适配服务直接产生 HTTP 错误，源站可能从未见过该请求。

把最后一个 HTTP 状态归给源站，会误导重试、责任判断与告警路由。绕过适配器重试又可能绕过一项本来有效的政策。

响应修改模式同样需要分层：输入来自源站，适配服务可能改写，消费者还可能拒绝、截断或重新解释。适配成功不等于交付成功。

ISTag 标出决定所处的服务时代

每个 ICAP 响应都必须带 ISTag。服务可以用它表示软件、规则或数据配置状态。当变化使既有适配结果失效时，更换标签能让客户端清理与旧状态关联的缓存结果。

它比单个 HTTP 表示的 ETag 更接近服务级时代标识：一个标签可能覆盖该服务 URI 处理的许多对象。也正因如此，标签生成、集群发布和失效传播都是控制面。

标签不是密码学证明。它不说明包含哪些规则，不证明所有节点已同步，也不证明旧判断正确。两台错误部署的机器完全可能继续发出同一旧标签。审计应把标签绑定到配置清单、节点集合、启用时间和实际缓存失效动作。

OPTIONS、对象缓存与规则各有时钟

OPTIONS 宣告支持的方法、Preview 长度、传输处理、Allow、连接上限、有效期和 ISTag。OPTIONS 可以过期；适配结果有自己的缓存寿命；服务规则又可能在两者之间改变。

在 RESPMOD 中，适配后的源站对象不得比原对象过得更久，虽然可以更早过期。这保护了一条来源新鲜度边界，却不能证明规则时代仍有效。

一次缓存命中至少要回答三个问题：能力信息当时是否新鲜，结果是否仍在 HTTP 新鲜期，所用 ISTag 是否仍被服务接受。只展示当前标签，无法还原过去的决定。

封装偏移是地图，不是语义认证

Encapsulated 头给出请求头、请求体、响应头、响应体、OPTIONS 体或空正文的偏移。它让复合消息可以拆分，却不会验证嵌入 HTTP 的所有语义，也不会证明改写保留签名、引用或最终意图。

分块框架、预览终止、ieof、ICAP 最终状态和嵌入 HTTP 状态属于不同层。若只保存重新序列化后的 HTTP 对象，最能解释观察范围的边界反而会被抹去。

政策授权在状态码之外

RFC 3238 以及后续 OPES 文档讨论同意、通知、隐私、URI 解析、引用有效性、规则、信任域与跟踪。这些文档并不把所有 ICAP 部署都变成 OPES，也不会给某个状态码自动添上政策回执。

它们揭示的是缺失的控制记录：谁的规则选择了哪个服务，谁授权访问内容，在哪个信任域内运行，如何向参与者标明改写。传输状态与政策权限可以关联，但不能互相替代。

从终止分块到最终效果的证据链

先保存原始 HTTP 字节、角色与观察点。记录 ICAP URI、方法、连接身份、OPTIONS 内容、到期时间及 ISTag。验证所有封装偏移。

再记录预览请求长度、实收长度、终止分块、ieof、源站读取状态与客户端缓冲。保存 100 或最终状态、后续正文以及服务实际观察的字节区间。

发生改写时保存前后哈希和规则轨迹；使用缓存时保存键、新鲜期和标签比较；遇到 204 时证明原文如何被逐字重建。

最后才是下一跳 HTTP、源站来源、接收者交付、授权与已认证应用结果。任何一个中间成功都不能代替后一个阶段。

证据边界

本文不指向任何现实产品、代理、扫描器、部署或事故，也不声称预览或 ieof 本身不安全。它只保留协议已经给出的观察边界。

本文也不重复已有的 HTTP 100 Continue 历史文章。那篇讨论 HTTP 头部边界上是否值得发送正文；这里讨论封装正文内部的停点、适配服务与源站的不同身份，以及完整输入如何得到证明。

Heng Lu 关于最小初始规范和运行代码优先的论述，是明确披露的编辑视角。它们支持精简的公共线级合同与可复核的实际路径证据，不构成 ICAP 使用率或部署质量的测量。

窄结论足够重要：ieof 让“服务看到了全部正文”成为可核验事实；丢掉它，完整就重新变成猜测。

Sources