要約

  • CDNI Triggers v2 の 201 Created が証明するのは、トリガー資源の作成である。パージ、無効化、事前配置の完了ではない。
  • 改訂20では、上流要求を受理済みの中継 CDN が、後段 CDN の同期 HTTP 拒否を Error.v2 という非同期状態へ変換しなければならない。拒否元 PID の開示は任意である。
  • 完了、取消し、累積件数、復帰ノードの整合、利用者が見る結果は、それぞれ別の台帳として検証する必要がある。

状態資源は作業そのものではない

CDN A が CDN B に削除を依頼する。B は要求を認証し、トリガー資源を作って A に 201 Created と Location を返す。その後 B は CDN C に処理を渡す。C は未対応要素を見つけ、400 Bad Request で拒否する。

A と B の間では、資源作成に成功している。C では、処理開始前に拒否されている。この二つは矛盾しない。対象となる出来事が違うからだ。

2026年9月2日付の CDNI Control Interface / Triggers 2nd Edition 改訂20 は、この境界を詳しく規定した。Datatracker 上では CDNI ワーキンググループの active Internet-Draft、WG Document である。承認されれば RFC 8007 を置き換える文書だが、現時点では RFC でも IESG の承認でもなく、実装・導入の証拠でもない。

改訂19 からの重要な前進は、エラー処理と多段伝播を大きく具体化した点にある。ニュースの対象はパージ機能そのものではなく、一度受理した後の拒否をどの証拠形式で返すかである。

同期エラーが非同期の証言へ変わる

B 自身が資源作成前に不正な形式、権限不足、未対応アクションを検出すれば、4xx を返して資源を作らない。ところが B が受理した後、C が返す 4xx/5xx は、すでに終了した A–B 間の HTTP 応答にはできない。

そこで改訂20は、B に変換を義務づける。C の同期拒否を Error.v2 Description にし、B のトリガー状態資源へ格納する。C が受理後に非同期で失敗した場合も、同じ errors 配列を経由する。A は後の GET で failed と eunsupported などの理由を知る。

失敗は C では直接応答だったが、A では B が後から伝える記録である。最初の HTTP ステータスだけを保存する監視は失敗を見落とす。最終エラーだけを保存し、変換主体を捨てる監視は来歴を失う。

さらに、B は C の CDN Provider ID をエラーに含めてもよいが、必須ではない。B 自身の PID を用いて C を秘匿することもできる。IANA の CDNI パラメータ登録簿は共有語彙を支えるが、語彙の登録は商流の透明性を保証しない。

完了には到達範囲がある

トリガーは通常 pending から active へ進み、complete または failed で終わる。中継 CDN は、自身と全下流 CDN が完了するまで complete を返してはならない。自身または一つの下流が processed を返せば、中継も processed を返す。

この processed は重要だ。要求は受理したが、今後の状態更新を提供しないという可視性の限界を表す。監視側がこれを完了へ丸めれば、仕様が残した不確実性を勝手に消してしまう。

資源 URI には RFC 9562 に沿う一意な UUID が推奨され、削除後も URI を再利用しない。一意の識別子は台帳の衝突を防ぐが、処理成功を認証するものではない。

一つの枝が失敗しても、中継は自身と全下流の処理が終わるまで failed を確定しない。終端状態は、宣言された処理グラフが収束した結果であり、最初の故障時刻でも利用者の復旧時刻でもない。

数字は重複を含むよう設計されている

改訂20は、影響したオブジェクト数、ノード数、総バイト数を累積進捗として扱う。複数ノードや下流 CDN をまたいで集計し、同じオブジェクトが複数ノードで処理されても重複排除しないことを推奨する。目的は、想定より大きい・小さい処理を見つけることだ。

したがって 1万件という表示は、一意な1万オブジェクトを意味しない。逆にゼロ件でも、既知オブジェクトに一致しないパージや無効化は成功完了になり得る。累積作業量、対象集合、利用者結果は別の測定である。

取消しは時間競争、削除は記録の消去

取消し処理の実装は任意である。B が取消しを受理しても、A が直前に見た pending はすでに active かもしれない。active や processed の仕事が、停止より先に完了することもある。cancelling は停止中という証拠であり、影響停止の証明ではない。

削除すると状態資源は消え、後の GET は 404 Not Found になる。だから草案は、終端状態を確認したい場合には削除より取消しを勧める。204 No Content が示すのは記録の削除であって、キャッシュ上の過去動作の巻き戻しではない。

対象データの時点も重要だ。active 開始前に取得済みのデータはパージ・無効化対象であり、取得中のデータも対象にすべきである。開始後に取得したデータは原則対象外だが、その分離を常に実現できるとは上流は期待すべきでない。順序指定なしに直後の事前配置を走らせれば、新しい内容まで先行パージに巻き込まれる。

この位置づけは、RFC 6707 の問題設定、RFC 7336 の CDNI 枠組み、RFC 7337 の制御要件に連なる。RFC 9110 が HTTP の意味を定義しても、成功コードの証明範囲はその HTTP 操作に限られる。

見えなかったノードが戻る日

個別ノードの一時停止は内部運用状態として扱い、それだけで公開トリガー状態を変えるべきではない。復帰ノードは通常サービスに戻る前に、過去のトリガーと整合する状態へ直すべきだと草案はいう。

この抽象化はサービスを単純に見せる一方、証拠責任を下流へ預ける。上流の終端状態は、一時停止ノードを直接観察した結果ではない。ノード復帰後の利用者経路テストが必要なのはそのためだ。

複数経路が合流する diamond 構成は、伝播遅延や処理差で競合メタデータを生み、設定エラーとされる。PID 経路はループ検出に役立つが、上流に全事業者を開示する保証ではない。

仕様が整えるのは証拠の連鎖であり、現実を一語へ圧縮する仕組みではない。