HTTP 431：本文より先に大きすぎたリクエスト

要約

本文が空の小さな操作がゲートウェイに届く。ところが、長い Cookie、資格情報、表現の選好、追跡情報、転送文脈を伴っている。個々は妥当でも、合計は一つの受信側が選んだ予算を超える。

RFC 6585 は 2012 年、この状態を 431 Request Header Fields Too Large と名付けた。サーバーはフィールドが大きすぎるため処理を拒み、クライアントは小さくして再送できる。

RFC 9110 の 413 が扱うリクエストコンテンツとは違う。431 が扱うのは、解釈、権限、条件、経路を運ぶ制御の封筒だ。本文の開始前でも、リクエストは限界に達する。

RFC 9110 は、一つのフィールド行、値、フィールド部全体に事前定義の長さを置かない。とはいえメモリと解析時間は有限なので、実装ごとに処理する範囲を選ぶ。

一つの経路にも複数の予算がある。クライアントは生成でき、手元のプロキシは通し、エッジは拒む。別の経路なら異なる限界を持つオリジンまで届くかもしれない。同じバイト列が一方で成功し、他方で失敗しても、共通の HTTP 数値に反してはいない。その数値はないからだ。

431 は私的な予算を共通語にしただけで、どのホップが最小値を選んだかを単独では証明しない。上限を増やすべきだとも命じない。

RFC 6585 は二つの場合を認める。フィールド集合の合計が大きい場合と、一つのフィールドが原因の場合だ。後者なら、応答表現は該当フィールドを示すべきだとする。

単独なら意味を保ったまま短縮、更新、省略できることがある。合計超過は、多数の独立した追加が重なって生まれる。最大の一つを消しても次のホップに収まる保証はない。フィールド名は診断材料であって、経路全体の適合証明ではない。

責任も一箇所とは限らない。Cookie は複数応答の状態を蓄え、転送フィールドは中継で伸び、資格情報は更新で変化し、追跡基盤はアプリケーションの外側で値を追加する。

RFC 9110 は、処理したくない大きさのフィールドを受けたサーバーに適切な 4xx を求める。無視すると、リクエストスマグリングを含む解釈差の危険が増える。

フィールドは飾りではない。資格情報、更新条件、宛先、メッセージ解釈を運ぶ。あるホップが無視し、別のホップが適用すれば、二者は同じリクエストを扱っていない。切り詰めは条件付き更新を無条件にし、認証根拠を除き、境界理解を分裂させうる。

サーバーはリクエストを適用する前にフィールド部全体を受信しなければならない。後続部分に条件、資格情報、誤解を誘う重複がありうるからだ。安全な分岐は明示的な拒否と、意味を所有する側による再構築である。

削減後の再送は許されるが、成功は保証されない。下流の制限が低いかもしれず、消したフィールドが必須かもしれず、操作の期限が切れているかもしれない。以前の通信が不確実なら、既に作用したかも分からない。

再送は権威ある状態から再構成し、必要な資格情報と条件を保ち、アプリケーションが対応するなら冪等性の仕組みを用い、まだ実行する価値があるかを確認する。欠けたリクエストを速く繰り返しても意味は戻らない。

RFC 6585 は 431 応答の保存を禁じる。判断は特定のフィールド部、経路、現在の受信予算に属する。後で再生すれば、縮小済みのリクエストを拒んだり、一つの過去設定を別経路の規則にしてしまう。

受信側は現在の証拠から新しい 431 を返せる。キャッシュは古い解析判断を再利用可能な内容にはできない。

サーバーは必ず 431 を返す必要はない。RFC 6585 は、攻撃時には接続を落とすなどの措置が適切な場合を認める。詳細な診断を作るための読み取りと解析は、保護対象の資源を消費し、正確な閾値の公開は探索を助ける。

余裕があれば限定的な説明が正規の利用者を助ける。敵対的な圧力下では早期遮断が優先される。ただし接続切断だけではフィールド超過を証明できない。内部の観測は理由を区別する必要がある。

431 は本文が大きいとも、インターネット共通上限を超えたとも、悪意があるとも言わない。一つの受信側が、処理意思を超えた制御の封筒を拒んだとだけ述べる。

この狭い真実が、隠れた実装制限を修復可能にした。長期的な規律は、文脈を単に小さくすることではない。境界と所有者を持たせ、再構築可能にし、安全性を与える条件を「収めるため」に捨てないことだ。