要約

  • draft-ietf-httpbis-pre-denied-01 は、Sec-Purpose で宣言された目的を理由に関連要求を拒否したことを示す 419 を提案する。その表示は当該要求だけに適用され、同じ目的の次回要求が成功するかは決めない。
  • 宣言目的は要求メタデータであり、人間の身元、同意、悪意、将来の操作を認証しない。拒否を人物評価や恒久的なアクセス判断に昇格させてはならない。

ブラウザーは、利用者がリンクに触れる前にページを取得しようとした。Sec-Purpose は prefetch を示した。サーバー側の制御はその要求を断ったが、数秒後に本人が実際に移動すると通常の応答を返した。

二つの応答は矛盾しない。最初はユーザーエージェントが作った推測的な仕事への判断であり、後者は実際のナビゲーションへの別の判断である。前者を「利用者が拒否された」と記録すれば、技術的な文脈が人間への権限判断にすり替わる。

The Purpose Declined HTTP Status Code の第 01 版は、2026 年 9 月 9 日に IETF HTTP ワーキンググループのアクティブな Internet-Draft として公開され、2027 年 3 月 13 日に失効予定である。標準化トラックを意図するが、変更・置換・失効し得る作業文書だ。資料凍結時点の IANA HTTP Status Code Registry に 419 の割当てはない。したがって、RFC、登録済みコード、実装普及、相互運用実績として扱わない。

目的は要求の属性であって主体の資格ではない

Fetch Standard は、ユーザーエージェントが要求目的を Sec-Purpose で表す仕組みを持つ。推測取得は、後の待ち時間を短縮するために、通常のナビゲーションより先に表現を求めることがある。

しかし、値が正しいからといって、利用者が取得を命じたとは限らない。ブラウザーの予測器が選んだかもしれず、利用者はリンクを開かないかもしれない。値は人を認証せず、契約への同意を示さず、業務処理の許可にもならない。

受信側が得るのは「この要求はこの目的として提示された」という限定情報である。そこから資源配分を変えることはできる。だが、主体の評価には本人性と権限の別証拠が必要になる。

この区別を失うと、安全制御はブラウザー最適化を攻撃意図として数え、商品分析は受理されたプリフェッチを利用者の転換として数える。どちらも、メタデータに与えられていない権力を付け足している。

新しい番号は拒否能力を新設しない

草案は、新たな機能を導入しないと明記する。オリジンやその代理は、以前から推測要求を提供しない選択を持っていた。提案は、その理由を 503 や 403 より区別しやすくする。

RFC 9110 の 503 は、過負荷や保守による一時的な処理不能を表す。目的上の拒否を同じ箱に入れると、運用者は容量事故を推論しやすい。419 は「宣言目的に基づく拒否」という狭い分類を提供しようとする。

分類は権限の出所ではない。無関係なプロキシが番号を付けても、オリジンを代表する権利は得られない。正しく整形された応答も、実装が真の理由を述べたことまでは証明しない。

運用記録には、方式、対象、Sec-Purpose、時刻、接続、応答ホップ、委任関係、ポリシー版、キャッシュ情報を残すべきである。番号だけでは、誰が何を判断したかを復元できない。

ゲートウェイの判断は実在するが、オリジンの内部事実ではない

草案は、オリジンサーバーに加え、その代理として行動する CDN やリバースプロキシにも生成を認める。一方、オリジンの代理ではないプロキシは生成すべきでない。

委任されたエッジが返した 419 は、単なる雑音ではない。そのエッジがオリジンのために制御を執行したという意味を持ち得る。ただし、オリジンアプリケーションが要求を見た、過負荷だった、すべての経路が同じ判断をする、という証拠にはならない。

TLS 終端、経路、Via、Proxy-Status、相関 ID、オリジンとエッジの記録を組み合わせ、証拠が示す最も具体的な決定点を記す必要がある。RFC 9209 の診断は中継処理の説明に役立つが、オリジンの健康を代わりに証明しない。

委任の存在と内部状態の推測を混同しないことが重要だ。エッジは本当に決定できる。しかし、その決定を根拠に別の構成要素の状態を宣言することはできない。

同じ目的でも次回は別の事実になる

提案は、表示が関連要求だけに適用されると定める。同じ目的を持つ将来要求は成功することも失敗することもある。この時間的な限定が、恒久的なアクセス規則への変換を防ぐ。

次回までにキャッシュが温まり、負荷が変わり、表現の費用が下がり、実験設定やゲートウェイルールが更新されるかもしれない。通常ナビゲーションは別経路を通ることもある。逆に、目的とは無関係な認可や障害で失敗する場合もある。

安全な実装はイベントを時刻付きで保存し、資源の永続属性にしない。短いローカル抑制やジッター、限定的な再確認は可能だが、次回の結果は新しい応答から得る。

過去の結果を将来の権限として再利用すれば、最適化機会を永久に捨てるか、拒否される仕事を送り続けるかのどちらかになる。どちらも仕様ではなく、時間範囲を発明した側の責任である。

キャッシュは判断の対象を増やしてはならない

草案では、提案コードはヒューリスティックにキャッシュ可能ではなく、キャッシュすべきでもない。ある要求への拒否を再利用すると、サーバーが評価していない要求まで古い判断に従わせるからだ。

RFC 9111 はキャッシュの一般則を提供し、RFC 9211 の Cache-Status は転送・再利用・再検証の手掛かりを与える。ただし、キャッシュ診断はポリシーの理由を証明せず、419 はキャッシュ経路を証明しない。

同じ応答が連続するとき、新たな百回の拒否なのか、一回の拒否の百回再生なのかを分けなければならない。Age、指示、キー、転送記録、決定点のログが、件数の意味を決める。

本文を隠れた機械契約にしない

この応答は利用者表示を目的とせず、本文はゼロ長が望ましい。本文が送られても破棄すべきだとされる。一般エラーページの文言を解析して安定した規則とみなすことを防ぐためである。

テンプレートが「容量不足」「権限なし」「後で再試行」と書いても、実際の判断と一致する保証はない。提案コードが述べるのは宣言目的による当該要求の拒否までで、追加説明には独自の定義と由来が要る。

また、応答の有無が内部状態を漏らす可能性も指摘される。キャッシュ温度、容量閾値、実験フラグと連動すれば、外部から状態遷移を探れる。内部運用の明瞭さと外部への露出を同時に設計しなければならない。

情報源と限界

凍結資料は草案第 01 版、Datatracker の状態・履歴・参照、HTTP WG、Fetch Standard、RFC 9110/9111、代理・キャッシュ診断、BCP 14、IANA 登録表を含む。提案内容と凍結時点の文書状態を示す。

実装、採用率、実事故、ベンダー動作、最終標準化は示さない。冒頭は推論境界を調べるための構成例であり、特定サービスの報告ではない。

出典