摘要
- 在
draft-ietf-cdni-ci-triggers-rfc8007bis-20中,下游 CDN 必须回应取消请求,但是否真正实现取消仍是可选项;即使请求获接受,原任务也可能抢先启动或正常完成。 cancelling、cancelled、processed、complete与删除分别证明不同阶段。删除状态资源可能先消灭证据,却没有阻止远端分支继续执行。
缓存清除通常从一个很短的动作开始:向接口发出 purge。可一旦命令穿过上游 CDN、传递 CDN 与多个下游节点,“停止它”就不再是同一个动作的反向播放。
2026 年 9 月的 CDNI Control Interface / Triggers 第二版修订 20 允许上游 CDN 要求下游预置、失效或清除内容与元数据。预置是提前取得副本;失效是再次使用前必须重新验证,但不要求擦除;清除则要求不再持有目标数据。这三个动作改变的状态不同,失败代价也不同。
取消命令也要参加竞赛
草案要求下游回应取消,却明确说真正取消可以不实现。对 pending 任务的取消即使获接受,任务仍可能在请求处理前启动。对 active 或 processed 任务,系统应当停止,但不能保证它不会在此期间正常跑完。
因此,cancelling 只表示“已经要求停止”。只有处理在正常结束前真正停下,状态才成为 cancelled。若原动作先抵达终点,最后看到的可能仍是 complete 或 failed。操作员的意图有时间戳,执行结果也有自己的时间戳;二者不能互换。
清除范围本身也有时间边界。进入 active 之前取得的数据必须纳入;正在取得的数据应当纳入;处理开始之后才取得的数据原则上不应纳入,但草案承认这并非总能做到。一次合法清除并不会在所有缓存进程上切出绝对整齐的瞬间。
替换内容最能说明后果。若旧清除尚未结束,新版本已经预置,旧命令可能在新副本抵达之后把它删除。执行策略扩展可以让后一个触发器依赖前一个触发器完成。依赖关系不是流程装饰,而是防止两条正确命令产生错误顺序的控制面。
processed 是诚实的不确定性
草案把 processed 定义为:触发器已经创建,之后不再更新状态,并且无法确认完成。下游仍继续处理,并应尽可能给出预计完成时间。它不是含蓄的成功,也不是隐藏的失败,而是接口对自身可观察能力的上限声明。
收到 processed 后,运营系统不应把事项关闭,而应转入证据队列。清除可结合最后一次状态表示、对象或错误信息、源站请求变化、缓存探测以及实际返回的版本;预置则应从目标地域发起受控请求,确认准备好的确是预期版本。独立观察不能制造绝对确定性,却能避免把没有回执误写成正面回执。
HTTP 状态还处在更早一层。201 Created 证明触发器资源已建立;202 Accepted 证明命令被接纳但尚未完成;删除返回 204 No Content 证明状态资源已移除。它们都没有说明每个缓存节点还保存或交付哪些字节。
删除既是控制动作,也是证据选择
草案说,删除与取消相似,关键差别是删除完成后资源不可再查询。因此,如果事后还需要状态,应优先取消而非删除。
这不是 API 风格问题。删除 pending 任务不能保证它尚未启动;删除 active 或 processed 任务也不能保证它停止。运营者可能得到一个完全有效的删除响应,同时失去最直接的状态入口,而远端清除仍在继续。
自动过期是更安静的证据丢失。下游可以在终态之后移除资源,后续查询返回 404;它必须公布保留时长,并且在执行或继续向下游分发仍可能发生时,不应过期 processed 资源。永不复用的 UUID 防止新任务冒充旧任务,却不能让已经消失的记录重新可见。
级联必须等到最后一条分支
传递 CDN 若把触发器继续向下游分发,就不能在自身完成时代表全网宣布 complete。只有它和所有受影响下游都完成,汇总状态才能完成。任何一条分支是 processed,汇总也必须保留 processed。取消则要保持 cancelling,直到每条分支分别到达 cancelled、complete 或 failed。
这个规则不让最快节点替最慢节点作证。它也要求保存原始触发器与各级资源的映射、CDN 路径、分支错误、状态变化时刻以及之后观察到的内容结果。
菱形拓扑会让同一 CDN 经不同路径取得相关对象,传播延迟和元数据还可能冲突;草案把这种情形视为配置错误。扩展状态中的对象数、节点数与字节数能帮助发现异常,但字段是可选的,同一对象在多个节点被处理时也不会去重。它们是报警器,不是唯一对象账本。
complete 很强,但只回答它被问到的问题
草案禁止在触发器列出的全部操作成功前报告 complete,级联下游也包括在内。这是实质性的协议保证,不能被贬成“状态都不可信”。
但保证的边界仍由请求决定。若失效或清除没有匹配任何已知对象,可以零影响成功完成;匹配表达式也可能与操作员心中的集合不同。CDNI 又把控制、元数据、请求路由与日志划成不同接口。控制动作完成,并不自动证明最终用户实际收到的表示。
稳健的运行手册至少保存五个时刻:原始触发器、相邻 CDN 的接纳、取消或删除请求、每条级联分支的终态,以及对内容效果的独立观察。它不会仅凭 cancelling、processed 或某个 2xx 就启动下一个不可逆动作;也会在事故前演练合作方是否真的支持取消、扩展状态与分支错误回传。
修订 20 仍是 Internet-Draft。冻结的 IANA 登记表仍显示 RFC 8007 的旧载荷类型,而非草案提议的 .v2 条目;现有材料也不能证明任何具名 CDN 已部署它。草案的当前价值正在于这种克制:取消获接受,只能证明停止请求进入了系统,不能证明清除没有发生。
来源
- CDNI Triggers Datatracker 页面
- CDNI Triggers Datatracker 历史
- CDNI Triggers 第二版修订 20
- CDNI Triggers 第二版修订 19
- RFC 8007:CDNI 控制接口 / Triggers
- RFC 6707:CDNI 问题陈述
- RFC 7336:CDNI 框架
- RFC 7337:CDNI 需求
- RFC 8006:CDNI 元数据
- RFC 8008:CDNI 覆盖与能力
- RFC 8009:CDNI 日志接口
- RFC 9110:HTTP 语义
- RFC 9562:UUID
- IANA CDNI 参数表
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Running-Code Primacy
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance

