摘要

  • CDNI 可选的 Complete 筛选集合同时收纳成功完成的任务，以及不再提供状态更新的 processed 请求。仅凭进入这个集合，不能宣布所有操作成功。
  • 单项 complete 状态要求相关操作成功完成；在级联网络中，还必须保留相关下游的结果。某个下游只能报告 processed，中间网络不能把它升级为 complete。
  • 预计完成时刻用于协助安排工作，不是完成证明。这套触发接口不要求互联 CDN 的时钟同步，跨网络时间数字不能自行拼成因果顺序。
  • 失效处理、清除、预先获取、取消和删除报告各有不同效果。后续工作应依据真正需要的前置结果，不能依据一个看起来干净的报表。
  • 本文的内容替换场景是对规范语义的分析，不是某家 CDN 的实测缺陷、客户事故或普遍采用情况。

一次替换，等错了信号

设想内容发行方要在原有网址换上新材料。它先要求分发伙伴清除旧材料，再打算预先获取替代内容。伙伴接受了清除请求。过了一会儿，对应报告从活动任务移到 Complete 集合，报表看起来已经收尾。

负责替换的人可能因此放行下一项工作。然而，他真正需要知道的不是“以后还会不会收到报告”，而是“可能影响新内容的旧清除操作是否已经成功结束”。这两个问题可以得到不同答案。

如果单项报告的状态是 processed，规范表达的是请求已经被接受，并且不会再提供状态更新。这个状态可以用于无法确认完成的情形。报告进入终结归类，并不补上原本无法提供的结果证明。

这里没有指认真实网络犯错。场景的用途，是把 RFC 8007 明确保留的一条语义边界放到实际决策面前：一个伙伴可以坦诚地提供有限报告；另一个伙伴不能悄悄把有限报告当成更强的授权依据。

集合名称与单项状态不是同一个承诺

RFC 8007 于 2016 年 12 月发布，属于 IETF Standards Track 文档；RFC Editor 记录将其列为 Proposed Standard。它规定 CDNI 控制接口中的触发部分，让上游 CDN 请求下游 CDN 获取、使其失效或清除元数据及内容，并查看工作状态。

它不是整套 CDN 商业关系的统一管理规则。控制、元数据、请求路由和日志各有作用。初始配置、部分发现机制以及本地访问控制，并没有因为触发接口存在而变成全球集中式调度。

下游为请求方提供状态资源的集合，还可以提供筛选视图。这些筛选集合是可选实现；如果实现了，就必须在总集合中给出相应链接，而不是要求所有参与者猜测一个固定地址结构。

其中叫作 Complete 的集合，不只包含单项状态为 complete 的任务，也包含不会再更新的 processed 请求。名称适合描述跟踪工作的归类，但不能替代每项操作的结果。

小写的 complete 是单项成功状态。processed 则说明请求被接受、以后不再更新，包括无法确认完成的情形。读者若把这两个词都理解成“事情做好了”，就抹掉了接口专门保留的区别。

processed 不是一律失败，也不表示没有发生任何工作。它同样不保证成功、不保证实际工作已停止、不保证未来不会继续产生效果。它所界定的，首先是报告能够继续提供什么。

所以，观察者的跟踪任务可以结束，依赖结果的下一项决策却未必已经具备条件。一个队列被整理干净，不等于所有使用这个队列的人都得到同样强的答复。

接受请求，意味着有了可查看的资源

下游接受触发请求后，创建状态资源，并以 HTTP 201 返回其位置。请求方拿到了以后查看进展的参照。这不是一张说明工作已经完成的通用收据。

返回的位置必须按实际链接使用。上游不能推断资源地址的结构，不能把示例路径当成所有服务的固定规则。状态资源即便后来删除，其 URI 也不得再被复用。这样，原请求的身份不会被新工作静默替换。

能够跟踪执行的下游，可以报告等待、活动，再进入成功或失败结果。如果下游无法跟踪并报告进展，就必须用 processed 明示限制，并将资源放进 Complete 集合；规范还建议提供适当的预计完成时刻，帮助请求方安排后续获取。

有些请求本来就不需要新增动作。例如，清除目标尚未被下游取得，或者预先获取的内容已经存在且仍有效。规范允许这些任务正确地报告 processed 或 complete，并进入 Complete 集合。

因此，一个成功状态也不是“移动了多少字节”或“擦除了多少存储”的实测计数。必须结合请求类型、目标范围和实际结果理解，不能从报表归类直接推导物理变化。

一跳成功，不能代表整条级联成功

下游 CDN 还可能向更下游的伙伴分发内容。相关触发请求必须被转发。中间网络不是只完成自己的本地步骤，就可以替所有参与者签出成功结果。

RFC 8007 要求，相关下游全部报告 complete 以前，上一级不能报告 complete。只要某个相关下游报告 processed，中间网络也必须保留 processed，而不是把缺少的确认升级成成功。

这是一项关于答复含义的约束，不是要求一个中心批准所有网络的每一步操作。执行可以分散，汇总答复却不能声称拥有实际上没有取得的证明。

失败也未必等到所有目标停止才出现。某些网址或匹配模式已经遇到错误，另一些目标仍在执行，状态资源可以同时保留活动状态和局部错误信息。

错误描述应指出请求中哪些网址或模式受到影响，并且保留其原样，不能为了方便而扩大成一个更宽的范围。一个目标失败，不等于所有目标失败；另一个目标暂时没有错误，也不自动等于成功。

这使选择性继续成为可能。某项独立工作已有足够结果，不一定要陪着另一项不确定任务一起停下；依赖尚未确认结果的替换，则需要另一个决策边界。全面暂停与全面放行，都可能过于粗糙。

RFC 7337 的 CDNI 需求已经提出按操作特点报告完成、成功或失败，包括相关级联网络。它是 Informational 需求文档，不是另一份同等级的线协议。触发规范进一步给出了有限跟踪的词汇，而不是用一个成功标签掩盖能力差异。

使其失效，不等于擦除存储

预先获取要求下游取得元数据或内容。失效处理要求受影响的数据在再次使用前重新验证，但不要求把它们擦除。清除要求请求处理完成后，下游不再持有指定数据；以后需要时，又可以重新取得。

当前 IANA 触发类型登记保留了这些区别。一个“成功”应按具体操作来判断，不能把禁止直接复用与完成物理擦除混为一谈。

规范允许失效任务在部分相关缓存节点离线时报告 complete，但条件是这些节点恢复后，不得未经重新验证就使用受影响的数据。这里的成功承诺，是未来复用必须经过的约束，不是每一台离线设备的存储已经被清空。

清除或预先获取任务，则可以在离线缓存恢复后继续完成工作时报告 processed。如果操作被放弃，下游应当报告错误。把所有进入终结归类的任务一概写成“数据已删除”，会把不同操作的合规含义扭成同一物理结果。

这些承诺针对请求涉及的数据和分发关系。它们不是对整个互联网副本状态的证明。已经交付给接收者的材料，也不会因为后来改了报告状态就被收回。

两个请求按顺序发出，也可能交错执行

触发工作的开始时间和节奏由下游控制。清除及失效处理必须覆盖命令被接受以前已经取得的数据；规范建议不影响以后取得的数据，但同时说明，上游不能依赖这一排除始终可实现。

收到命令时已经开始的获取如何处理，也存在实现选择。发送方不能把自己的请求发送顺序，当成所有远端数据的统一切换线。

这正是 RFC 8007 建议先完成失效或清除，再启动相同网址的替代内容获取的原因。若两项操作并行，新的材料可能先被取得，随即又被尚未结束的旧操作影响。

在菱形分发结构中，还可能有多条合法上游路径。相同内容和相关命令可以分别抵达，下游可以把重复操作单独排程。一条路径已经清除完成，沿该路径开始预先获取；另一条路径的清除仍未结束，又影响了刚取得的替代材料。

规范描述了重新获取等行为如何缓和可用性后果。这不意味着第一次放行替换时，就已经得到了所有竞争命令的瞬时完成保证。

于是，请求方要明确自己等待什么。是相关清除的成功结果？是明知有限、经双方接受的估计安排？还是下一项工作根本不依赖那个不确定目标？Complete 这个集合名称不能独自决定这些选择。

预计时刻不会自己变成完成事实

可选的 etime 表示下游估计何时完成。它可以帮助安排后续预先获取，但不是一个保证在该时刻已经成功的证明字段。

状态资源的创建、修改及预计完成时刻由下游确定。这套接口明确不要求互联 CDN 的时钟同步。把不同网络的数字按大小排在一起，不能自行建立共同的因果顺序。

运营双方可以根据本地时间基础和不确定性另行安排进度。这是局部协议或决策，不是把 processed 重新解释成 complete 的理由。即使时钟碰巧非常准确，预计完成仍然只是预计。

HTTP 条件请求可以节约观察成本。RFC 8007 建议对状态资源和集合使用 ETag。当前 HTTP 语义及缓存规范有助于理解这种方法，但没有把它变成远端动作的证明。

一个不再变化的 processed 报告可以正确返回 304，说明报告表示没有改变。它不能补上报告方已经明示无法继续提供的完成结果。更频繁地读取同一内容，并不会扩展原有观察承诺。

取消与删除报告，都不是回滚按钮

服务必须适当回应取消命令，但实际执行取消是可选能力。答复可以表示对应工作已不活动，也可以表示取消被接受但工作仍在进行，或者表示不支持取消功能。

等待中的任务可能在取消被处理之前开始。活动中的任务也未必立即停止。已经发生的效果不会因此自动逆转；已处于 complete 或 failed 的任务，更不能事后被改成已取消。

协议字符串还必须按核实后的值使用。已验证的技术勘误 5053将状态值纠正为 cancelling、cancelled；5054纠正了 ecancelled。编辑勘误 5064补明取消示例，与删除状态资源的示例区分。解释文字可以自然本地化，线协议的值不能随英文拼写偏好改变。

删除状态资源会移除可查看的资源及其集合引用，效果类似取消，却不保留这份后续报告。随后 GET 出错，只说明原有参照不再可访问，并不说明删除以前发生的是成功还是失败。

自动保留期限也是观察边界。若下游会清理旧资源，必须按规范公布相关保留时长。终结报告至少保留二十四小时是建议，不是无条件强制下限。请求方应在所需结果消失以前取得它们，不能把报告不可见理解成操作成功。

安全传送的答复，仍可能是有限答复

触发工作必须限制在请求上游对应的数据范围内。菱形结构中的多条合法获取路径，不意味着任何请求方可以干预其他租户的数据。

状态集合属于请求方，不能暴露给其他 CDN。规范要求 TLS 与远端认证，除非有其他方式保护交换信息。具体访问控制由下游决定，商业信任安排则不在协议定义之内。

当前 TLS 使用建议替代了原规范引用的较早建议，但受保护的连接本身不会加强一项操作的结果语义。它可以帮助确认答复经过预期的安全关系传来，不能证明所有缓存动作成功。

CDNI 框架、元数据接口和日志接口提供补充依据。某一处交付顺利、某份日志正常，并不能替所有离线节点及更下游伙伴证明数据操作完成。

资料与依据

以下一手文档支持协议语义及相关纠正。后续决策建议是作者分析，不是新加入的标准要求，也没有测量实际采用范围。