要約

  • RFC 9745のDeprecationは資源がいつ非推奨になるか、またはなったかを示し、RFC 8594のSunsetはURIがいつ応答しなくなる見込みかを示す。どちらも既定では応答対象の資源に限られたヒントであり、移行済みの証明ではない。
  • クライアント切替記録には、観測したヘッダーとリンクだけでなく、承認された対象範囲、代替先の差分、利用者の責任者、利用観測、互換試験、例外、復旧条件、停止後の実測を結び付ける必要がある。

分析

廃止の兆候は、障害より先に正常応答の中へ現れる。あるプログラムがいつものURIへ要求を送り、成功応答を受け取る。その応答には新しくDeprecationの日付がある。サーバー側は正しく予告した。しかしクライアント用ライブラリーが未知のヘッダーを捨て、監視が失敗率しか見ていなければ、担当者には何も届かない。

RFC 9745は、この予告を共通の形式にした。Deprecationは構造化フィールドの日付である。未来なら非推奨が効力を持つ予定日、過去なら効力を持った日を表す。ここで大切なのは、非推奨の宣言自体は資源の動作を変えないという点だ。日付を過ぎても同じ応答が返ることはあり得る。ただし利用者は、それ以前と同じ動作が今後も続くとは仮定できない。

同じRFCはdeprecationリンク関係も定める。提供者は、方針、日程、後継資源、移行方法などを説明する場所へ利用者を導ける。IANAへの登録はリンク関係の意味を共有可能にするが、個別文書の完全性や最新性を保証しない。リンクがあることと、各クライアントが必要とする差分が書かれていることは別である。

RFC 8594のSunsetは次の局面を扱う。これはURIが将来のある時点から応答しなくなる見込みを伝える。やはり確約ではない。指定時刻まで必ず利用できるとも、その直後に必ず停止するとも限らず、停止後がエラー、転送、接続不能のどれになるかも示さない。Deprecationと併記する場合、RFC 9745はSunsetを非推奨日より前に置くことを禁じる。時系列の矛盾を防ぐ規則であって、クライアントの準備完了を示す規則ではない。

観測したURIと影響範囲は同じではない

両ヘッダーは原則として、それを返した資源に適用される。サービスの入口で示した日付が特定版の全経路に及ぶ、と提供者が別途定めることはできる。だが、その規則を知らない利用者には拡張範囲が見えない。入口を通らず個別経路だけを呼ぶプログラムは、通知そのものを一度も受け取らないかもしれない。

したがって一つのヘッダー採取結果から、全メソッド、全地域、全顧客が同じ撤去対象だと広げてはいけない。反対に、ある経路にヘッダーがないだけで対象外とも断定できない。RFCがこれらを任意のヒントと位置付け、情報なしでも動けるクライアントを求めるのは、この観測の限界を前提にしているからだ。

証拠として残せるのは、正確なURI、観測時刻、応答の指紋、値、そして範囲を拡張する明示的な規則である。サービス全体という表現には、それを決める権限者が必要だ。

リンク先は自動切替の許可証ではない

移行文書に新しいURIが書かれていても、無人で本番通信を向け直してよいとは限らない。RFC 8594は、機械可読な移行情報が大規模な資源識別子の変更を起こし得るため、真正性、正確性、適用範囲を確認すべきだと警告する。別の資源を管轄しない方針が、その資源まで奪うことを防ぐ必要がある。

実務上、URLだけ同じ意味で置き換わる例は少ない。新しいホストは認証元、トークンの対象、権限、上限、エラーの語彙を変えるかもしれない。入力欄の既定値や出力順序が違えば、利用側の判断も変わる。読み取りには安全な転送でも、署名付き書き込みには失敗し得る。データ保存地域の変更は技術試験だけでは承認できない。

これらは標準ヘッダーが解決すべき問題ではない。ヘッダーは意図を伝える。具体的なクライアントを移す側は、代替先が自分の条件で成立することを別に確かめる。

切替記録に必要な五つの束

第一は通知の束である。正規URI、観測時刻、応答指紋、Deprecation、Sunset、関連リンクを保存する。明示された範囲と、その範囲を決めた権限者も記す。説明が衝突する場合は、一つに丸めず未解決として残す。

第二は代替先の束である。新旧の要求形式、応答意味、認証、認可、トークン対象、利用上限、順序、再試行、保存期間、地域提供の差を列挙する。文書は提供者の説明の証拠であり、小規模試験は特定条件での挙動の証拠である。役割を取り違えない。

第三は利用者の束である。既知のクライアントごとに責任者、重要度、最後に見えた利用、観測元、移行状態、次の判断日を持たせる。利用ゼロには必ず視野の限界を書く。キャッシュ、代理、年に数回の処理、別地域、災害用環境は通常のログに現れないことがある。

第四は例外の束である。後継版に機能がない、データ所在地の承認が済まない、外部製品の更新待ちといった理由を、決定者、暫定対策、失効日と組にする。古い版を使っているという状態だけでは、例外を正当化できない。

第五が停止判断の束である。先行利用者、成功条件、中止条件、復旧先、復旧を開始する兆候、戻せる最終時刻を決める。そして予定時刻の後に旧資源を実際に観測する。継続したなら延長の事実、早く止まったなら逸脱の事実を残す。過去の予定を書き換えて整っていたように見せてはならない。

一つのカウントダウンにしない

非推奨日は資源の推奨状態についての判断である。Sunsetは将来の応答性に関する見込みである。クライアントの完了目標、例外の失効、復旧可能期限、実際の停止時刻はそれぞれ別の時計だ。

これらを一つにすると、日付が来たから止めるという早計と、まだ応答するから決めないという先送りが同時に生まれる。時計ごとに、誰が動かせるのか、何を根拠に動かすのか、誰が影響を受けるのかを示す方がよい。

出典

  1. RFC 9745 — The Deprecation HTTP Response Header Field
  2. RFC 8594 — The Sunset HTTP Header Field
  3. IANA Link Relation Typesレジストリ