要約

  • HTTPbisは2026年9月9日、draft-ietf-httpbis-pre-denied-01を公開した。現行のワーキンググループdraftであり、RFCでも、IANAが419を割り当てたという事実でもない。
  • 01版は名称を「Preliminary Request Denied」から Purpose Declined に変え、419を提案し、Sec-Purposeで宣言された用途に基づく拒否へ意味を広げた。Fetchで現在定義されている値はprefetchだけだ。
  • オリジンと、その代理として動くゲートウェイは応答を生成できる。独立プロキシは生成すべきでない。これは実装能力ではなく、誰がサービス方針を表明できるかという境界である。
  • コードは判断規則を示さない。用途、決定主体、委任、ポリシー版、時刻、キャッシュ処理、結果を結ぶ最小記録を私は提案する。これはDaniel Kadeの編集上の提案であり、draftの要件ではない。

番号より重要な変更が入った

9月9日08時56分UTC、Datatrackerに The Purpose Declined HTTP Status Code の01版が載った。00版は番号を一般的な4xxのままにし、prefetchやpreloadに向けた「Preliminary Request Denied」を想定していた。新しい本文は番号を419とし、要求が自ら宣言した用途を理由に拒否される場合へ対象を広げた。

ただし、419を既成のHTTPコードとして扱う段階ではない。文書はHTTPbisのActiveなワーキンググループ文書で、IETF streamに属し、想定ステータスはProposed Standard、shepherdはTommy Paulyである。一方、IESG上はI-D Existsにとどまり、担当Area Director、処理段階、telechatはいずれもない。IANAの現行登録簿でも419-420はUnassignedのままだ。

この改訂が加えた重要な一線は応答の主体にある。オリジンサーバーは419を生成できる。CDNやreverse proxyのようなゲートウェイも、オリジンの代理として行動していれば生成できる。独立プロキシはそうすべきではない。

ここで問われるのはパケットを返す技術的能力ではない。中間装置なら任意の4xxを作ること自体はできる。問われるのは、その拒否をオリジンの用途方針として語る資格だ。経路上でオリジンに近いことは、委任を受けたことと同じではない。

Sec-Purposeが運ぶのは申告だ

Fetch Standardでは、Sec-Purposeは即時利用とは異なる目的を持つ要求を示す構造化ヘッダーである。この記事の時点で定義済みのtokenはprefetchのみだ。サーバーは申告を見てキャッシュ期限を調整したり、prefetchを認めなかったり、訪問数を別に数えたりできる。

「Purpose Declined」という広い名称は、今後ほかのtokenが定義されても使える余地を作る。だが、名称の変更だけでtokenが増えるわけではない。サーバーに新たな強制力を与えるものでもない。サーバーは従来も要求を拒否できた。draft自身が述べるとおり、追加されるのは能力ではなく、クライアントと運用者に対する判断の読みやすさだ。

その読みやすさには限界がある。Sec-Purpose: prefetchは、クライアントがこの要求をどう申告したかを示す。利用者の本心、バックグラウンド通信への同意、発行したソフトウェア部品、申告の正確さまでは証明しない。419も、全prefetch拒否なのか、負荷、費用、地域、濫用対策、コンテンツ種別による条件判断なのかを明らかにしない。

したがって観測できるのは、用途の申告と、それを理由にした権限ある主体の拒否という二つの狭い事実である。トラフィック全体の正当性や利用者の意図まで判定したことにはならない。

委任は運用記録で確認できなければならない

エッジでは、ポリシーを所有する組織と応答を生成する部品が別になる。CDNはアプリケーションに届く前に接続を終え、tenantごとの規則を実行できる。reverse proxyも同様だ。帯域やオリジン負荷は減るが、障害時には「誰の判断か」が分かりにくくなる。

ステータス行だけでは、アプリ自身の判断か、明示的に委任されたルールか、管理上独立した中継者の介入かを区別できない。どのオリジンが委任したのか、どの版のポリシーが有効だったのか、例外条件を評価したのかも分からない。

一方、公開応答に私的な規則を詰め込むべきでもない。draftは用途別拒否がサーバー内部状態を漏らし得ると注意している。そこで必要なのは、応答に対応する管理下の最小記録だ。正確なSec-Purpose token、決定部品と役割、委任したオリジンまたはtenant、安定したポリシーIDと版、判断時刻、結果、送ったキャッシュ指示、安全に開示できる理由区分を結ぶ。

これは利用者の行動を網羅的に記録する提案ではない。争われた判断を再現し、ゲートウェイが委任の範囲内で動いたか確認するための限定された証拠である。

キャッシュ禁止は権限の有効範囲を区切る

01版は応答本文をゼロ長とし、本文が届いても破棄すべきだとする。さらに419はheuristicにcacheableではなく、保存すべきでないと定める。一回の局所判断が、別の時点や別の要求にそのまま拡張されないための境界だ。

RFC 9110によれば、419を知らないクライアントも同じclassのx00、すなわち一般的な4xxとして扱う。RFC 9111は通常のキャッシュ条件を定める。draftの個別の不保存指示は、特定の負荷やポリシー版で出た拒否が、条件の消滅後も有効な答えとして再生されるのを防ぐ。

共有ゲートウェイで誤って保存されれば、応答はtenant境界を越えたり、更新後の方針より長く残ったりし得る。その後の419はオリジンの判断に見えても、オリジンは新しい要求を判断していない。キャッシュ処理を主体、委任、版と一緒に記録する理由はここにある。

公開プロトコルには最小の共通意味を、内部記録には責任の証拠を、理由の開示にはローカルな安全判断を割り当てる。この三層を混ぜない方がよい。

出典