Summary

  • RFC 6265では、サーバーがSet-Cookieで名前と値を渡し、ブラウザーが条件に合う後続の要求にCookieとして載せる。仕様はサーバーに、Cookieを少なく小さく保つよう求める。
  • 2012年4月のRFC 6585は、ヘッダー全体または一つのフィールドが大きすぎる場合の431を導入した。縮小して再送でき、431応答をキャッシュしてはならない。
  • HTTP/2とHTTP/3でも、受信側は処理したくない大きさのフィールド群を431で拒否できる。

差出人に戻された荷物

買い物客が同じサイトを再訪する。ブラウザーはトップページを要求し、ログイン状態、設定、実験用の識別値をCookieにまとめる。それらは以前、サイト側が保存を求めたものだ。ところが入口のゲートウェイかサーバーが決めたヘッダー上限を超える。返ってくるのはページではなく431。店は自分で詰めた荷物を客に持たせ、その客を門前払いした。

この往復は2011年4月のRFC 6265に記されている。サーバーのSet-Cookieを受けたブラウザーは、ドメインやパスなどの条件を確認して、後の要求で名前と値を送り返す。有効期限や適用範囲を定める属性そのものはCookieの名前と値として戻らない。だが一度保存された値は、条件に合う要求のたびに通信へ加わる。

同じ仕様の6.1節には、対照的な二つの指示が並ぶ。一般的なブラウザーはCookie一つにつき少なくとも4096バイト、ドメイン当たり少なくとも50個を扱えるようにする。一方でサーバーはCookieの個数と大きさを抑える。Cookieが毎回の要求に付くからだ。4096バイトはブラウザーの最低保存能力であって、入口のすべての装置が要求ヘッダー全体を受け入れるという約束ではない。保存できる量と読んでもらえる量は別の財布に入っている。

431は原因の名前で、修理の手順書ではない

2012年4月、RFC 6585はHTTPに四つの状態コードを加えた。431 Request Header Fields Too Largeは、フィールド群の合計が大きすぎる場合にも、一つのフィールドだけが大きすぎる場合にも使える。一つだけが原因なら、応答の本文でそのフィールドを示すべきだという。小さくした要求は再送してよい。431の応答をキャッシュすることは禁止される。

キャッシュ禁止は、ある要求への拒否を別の要求へ使い回さないために役立つ。しかし次のCookieを短くする機能はない。RFC 6585は共通のバイト上限を定めず、消すCookieも選ばない。攻撃を受けているサーバーは431を返さず接続を切ることもできる。利用者には単に「開かない」と見え、アプリケーションに届く前にゲートウェイが拒んだ可能性もある。

ブラウザーのCookieをすべて削れば要求は軽くなり得る。同時にログインや設定も消える。しかもサイトが同じ値を再び配れば、次の訪問でまた重くなる。案内ページが同じ巨大なヘッダーを必要とするなら、案内も閉じた門の内側だ。何を発行したか、どの範囲に何日間送らせるかを知る運営者こそ、荷物を減らす設計を変えられる。

圧縮して運んでも、門の幅はそのまま

2022年のRFC 9113は、HTTP/2サーバーが許容しない大きさのフィールドブロックに431を返せるとする。RFC 9114もHTTP/3のヘッダーセクションについて同じ扱いを記す。圧縮は送信中の表現を小さくできる。受信側が展開して扱うフィールド集合の予算まで消すわけではない。

障害調査では、ネットワーク上の転送量が小さいというグラフと、入口でヘッダーが大きすぎるという記録が同時に成立する。一つの巨大なCookieか、小さなフィールドの積み重ねかも分けて調べる必要がある。認証情報などCookie以外のフィールドも同じ予算を使う。四つのRFCには、Cookieが原因だった実際の431障害件数は載っていない。個別の事案を確定するのは、拒否地点での要求とログだ。

歴史を動かしたのは新しい番号だけではない。状態を発行する担当、入口を守る担当、要求を運ぶブラウザーの仕事が分かれたまま、一人の客の訪問が途切れる。431は差し戻し票に理由を書けるようにした。発行量を減らし、上限を揃え、小さな要求で届く復旧経路を用意する仕事はサイト側に残った。