要約

  • HTTP ワーキンググループの現行草案は、要求が宣言した Sec-Purpose を理由にサーバーがその一件を断る場合の 419 Purpose Declined を提案する。恒久拒否でも健全性判定でもなく、新しい拒否権でもない。2026 年 9 月 29 日時点で IANA は 419–420 を未割り当てとしていた。
  • 成否は番号の採用では決まらない。用途、オリジンから委任された判断点、非キャッシュ性、クライアントの未知コード処理、SLO の母集団、後続の実利用要求までを結べなければ、419 は下流で単なる 4xx に潰れ、誤った障害像が残る。

可用性会議で最初に問うべきなのは「何件失敗したか」ではない。「誰の、どの種類の要求を、どの約束に照らして失敗と数えたか」である。ところが多くの監視系は、非 2xx をひとまとめにして赤く塗る。利用者がページを開く前にクライアントが予測で送った要求も、利用者が今まさに必要としている要求も、同じ分母に入る。

先読みは賭けである。成功すれば体感待ち時間を縮められる一方、使われなければ計算、ストレージアクセス、帯域、ログ処理を消費する。クライアントは速さの利益を期待し、オリジンや CDN は処理費用を負う。したがってサーバーが一部の賭けを受けないこと自体は故障ではない。

しかし、その判断を 503 Service Unavailable で返すと、運用上の意味が逆転する。RFC 9110 の 5xx は、見たところ有効な要求をサーバーが満たせなかったという分類である。503 の増加を見た当番者が、容量や依存先の故障を疑うのは正しい。先読みの選択的拒否まで同じコードに入れた瞬間、その正しい推論が誤報を生む。

2026 年 9 月 9 日付の draft-ietf-httpbis-pre-denied-01 は、この混線を切り分けるため 419 Purpose Declined を提案した。サーバーが、要求の宣言用途を理由に当該要求を拒否した、と表す。HTTP ワーキンググループの現行 Internet-Draft であり、想定状態は Standards Track だが、RFC ではない。証拠を固定した時点で IANA の HTTP Status Code Registry は 419–420 を未割り当てとしていた。本文は将来の仕組みを既成事実として扱わない。

用途は要求の来歴であって、需要の証明ではない

WHATWG Fetch は Sec-Purpose を、利用者が直ちに使うこと以外の目的を示す構造化要求ヘッダーとして定義する。現在定義される唯一の token は prefetch で、近く必要になると予想した資源を先に取得するという意味である。Fetch の手順は、initiator が prefetch のとき Sec-Purpose: prefetch を設定する。

サーバーはこの宣言を使って、先読みのキャッシュ期限を調整し、先読みを許可せず、あるいはページ訪問の集計と区別できる。だが、ヘッダーが語るのは発生文脈だけである。利用者が後で遷移すること、予測精度、送信者の身元、利用者価値は証明しない。

ここで「宣言」と「権限」を分ける必要がある。クライアントには用途を説明する能力がある。オリジンには、その用途に今応えるかを決める責任がある。オリジンを代行するゲートウェイには、明示的な委任の範囲で同じ判断があり得る。要求経路上にいるだけの仲介者には、その権限はない。

これは共通仕様を薄く保つ設計である。共通層は、用途を一語で伝え、一回の拒否を区別できればよい。負荷、料金、顧客層、予測信頼度などの判断式を世界共通にする必要はない。将来の判断を、結果を負担する運用主体に残す。

一回の 419 を、資源の属性にしてはならない

草案は、419 の表示が関連する要求だけに適用されると明記する。同じ用途の将来要求は成功する場合も失敗する場合もある。つまりこれは判決ではなく、一回限りの受領書である。

先読みを拒否した時点ではキャッシュが冷たく、数秒後には温まっているかもしれない。負荷やポリシーも変わり得る。何より、利用者が実際にページを求める即時利用要求は、先読みとは異なる事実である。古い判断が後の要求を支配すれば、局所判断が不当に恒久化する。

そのため草案は 419 を heuristic にキャッシュ可能とはせず、さらにキャッシュしないことを推奨する。キャッシュが拒否を再利用すると、判断はオリジンとその時点の状態から切り離される。即時利用要求にまで古い 419 が返れば、任意作業の節約が本物の障害へ変わる。

応答は利用者表示を意図せず、長さゼロが望ましく、内容があっても破棄すべきだとされる。説明用エラーページを新設する仕組みではない。意味は要求文脈、状態コード、ポリシー版、トレースに残すべきで、先読みクライアントが表示しない本文へ隠してはならない。

実装試験では、同じ URL に条件を変えて複数回の先読みを送り、その後に通常要求を送る。拒否がキャッシュ再利用されないこと、次の要求が正しい判断点へ届くこと、空応答が UI に露出しないことを確かめる。番号を受信できた、だけでは範囲を証明できない。

419 を返せる主体には境界がある

草案は、オリジンサーバーと、その代理として動く CDN や reverse proxy に 419 の生成を認める。一方、オリジンの代理ではない proxy は生成すべきでない。この一文が、単なるコード割り当てを統制問題へ変える。

仲介者がパケットを見られることと、サービスの准入判断を所有することは別である。無関係な proxy が 419 を作れば、オリジンが自分のルールを適用する前に要求を消せる。ログ上はオリジン側の意図的拒否に見え、実際の意思決定者が隠れる。

したがって監査記録には、生成地点、オリジンとの委任関係、ポリシー版、参照した入力、対象範囲を含める。Sec-Purpose 自体は認証ではない。TLS やクライアント認証が別に存在しても、用途 token が身元証明へ昇格するわけではない。CDN が配信を代行している事実も、すべての准入意味を変更できる包括委任ではない。

草案は 419 がサーバー内部状態を漏らす可能性にも触れる。負荷や在庫に応じて応答が変われば、外部から閾値を探れるかもしれない。曖昧な 503 に戻すのではなく、観測可能にする粒度、問い合わせ頻度、公開してよい判断理由を局所的に設計すべきである。

後方互換は「4xx」までで、理由までは届かない

RFC 9110 は、未知の状態コードでも先頭桁の class を理解しなければならず、未知の 4xx を 400 相当として扱うよう求める。古いクライアントは 419 を成功と誤認しにくい。この互換床は重要である。

しかし Purpose Declined の意味が保存される保証ではない。SDK は bad request に正規化し、ログ基盤は other_4xx に集約し、再試行ライブラリは入力不正と同じ規則を適用するかもしれない。ダッシュボードが非 2xx をすべて障害にすれば、提案の出発点だった誤分類がそのまま残る。

Running-Code Primacy が問うのは、仕様書に区別があるかではなく、実際のクライアント、CDN、オリジン、キャッシュ、トレーサー、SLO 計算、通知経路が区別を運べたかである。IANA 登録が将来行われても、既存の集計規則を自動更新はしない。

最低でも三つの軸を保つ。要求が推測用途を宣言したか。誰が拒否を決めたか。その後の即時利用要求は成功したか。419 の件数だけを眺めても、クライアントが先読みを増やしたのか、ポリシーが厳しくなったのか、実障害が併発したのかを判別できない。

「503 はすべて障害」という誤りを、「419 はすべて無害」という誤りへ交換してはならない。誤設定、過剰拒否、偽造された 419 は利用者を害する。分類は報告された判断の種類を示すが、その妥当性を保証しない。

SLO の母集団を分け、後続需要で結ぶ

即時利用の可用性と、推測要求の受け入れ率は異なるサービス指標である。前者は利用者が今必要とする資源を得られるかを測る。後者は予測的な追加作業をどれだけ引き受けたかを測る。両者を一つの分母へ入れると、目的も責任も失われる。

完全な証拠は要求から始まる。request ID、method、target、initiator、Sec-Purpose、client build、cache state。次に判断点の identity、委任、policy version、rule、時刻。応答の status、cache control、content length、trace position。そして利用者の即時要求が後に来たか、その成功、遅延、転送量、オリジン処理、可視結果を結ぶ。

利用者が結局その資源を求めなければ、拒否は作業を避けた可能性がある。ただし節約額は測定が必要だ。すぐ通常要求が来て成功すれば、サービス健全性は確認できる一方、待ち時間の機会損失が残る。通常要求も失敗すれば、先の 419 は障害を帳消しにしない。通常要求へキャッシュ済み 419 が返れば、実装が scope を破った。

セキュリティ監視でも、419 急増だけで判断しない。ブラウザー更新、アプリの新しい prefetch 指示、攻撃者のラベル付け、オリジンポリシー変更のいずれでも起こる。用途と判断証拠を結んで初めて、capacity、product、edge policy、abuse のどこへ渡すべきかが決まる。

一次資料が示す範囲

現行草案は提案内容を、Datatracker は手続状態を、IETF 125 議事録は前身提案への強い adoption 支持を示す。Fetch は Sec-Purpose の意味を、RFC 9110 と 9111 は HTTP class と cache の境界を示す。IANA registry は固定日時点で 419–420 が未割り当てだったことを示す。

これらは、特定ブラウザーが全経路でヘッダーを送ること、特定 CDN が 419 を実装すること、監視製品が意味を保持すること、費用や遅延が改善することを証明しない。導入率、相互運用、削減効果、利用者成果には、実装マトリクス、制御試験、trace、cache 実験、policy record が要る。

この提案の強さは小ささにある。既存の拒否能力へ、故障とは違う名前を与える。一要求へ限定し、キャッシュを避け、利用者向け本文を持たず、生成主体をオリジン境界へ寄せる。それ以上の判断は運用者へ残す。

状態コードが現実を変えるのではない。コードを保存し、目的と権限を結び、後続需要まで観測した running system が初めて現実を変える。そこでようやく「サーバーは正常だった」という文章が、印象ではなく証拠になる。

出典