要約

  • No-Vary-Searchは、クエリの特定キーやキー順序がキャッシュ照合上の差にならないとオリジンが宣言する応答フィールドである。鮮度、検証、Vary、認可など他の再利用条件は残る。
  • 要求URLは書き換えられず、識別子もブラウザー、CDN、ログを通る。誤った同値宣言は、別の利用者文脈で取得した応答を共有キャッシュが返す原因になり得る。

/manual?doc=7&utm_source=mailの応答が保存されている。次に/manual?utm_source=event&doc=7が来た。アプリケーションはutm_sourceが文書を変えず、順序にも意味がないと知っている。しかしキャッシュにとっては別のターゲットURIだ。この無知を勝手な学習で埋めないことが、HTTPの保守的な出発点である。

2026年8月17日付のdraft-ietf-httpbis-no-vary-search-09は、その知識を明示的に渡す形式を定める。8月29日現在、HTTPBISのアクティブなInternet-Draftで、Proposed Standardを想定し、IESGでは承認後の告知待ち・ADフォローアップという段階にある。まだRFCではなく、IANA HTTP Field Name Registryにも登録されていない。

したがって、現時点の文書は検証可能な提案であって確定した制度ではない。実装テストはできるが、将来のRFC番号を先取りしたり、ヘッダーがあるだけで相互運用性や安全性が証明されたと扱ったりはできない。

厳密一致を狭く緩める

RFC 9111の再利用条件には、メソッド、ターゲットURI、Varyが指定した要求フィールド、鮮度または検証、キャッシュ制御が含まれる。クエリが違えば、通常はターゲットURIも違う。

キャッシュには、user、token、colorのどれが飾りかを判断する普遍的な知識がない。同じ本文が数回観測されたことも、将来の応答、ルーティング、同意、課金に影響しない証拠にはならない。

この草案が変えるのはURI照合の一段だけだ。古い応答を新しくせず、Varyを無効にせず、privateな表現を共有可能にせず、アクセス権を与えない。クエリが同値になっても、RFC 9111の残る条件はすべて評価される。

宣言者はオリジン、利用者はキャッシュ

値はRFC 9651のDictionaryで表す。key-orderはキー順序を無視できるかを示すBoolean、paramsは無視するキー名のInner List、exceptは逆に差を残すキーだけを列挙する。paramsとexceptは併用できない。

アプリケーション意味論を持つオリジンがフィールドを設定する。中間者は、その応答のオリジンとして振る舞う場合を除き、挿入、削除、変更してはならない。CDNがアクセス傾向から独自に規則を作れば、最も事情を知らない層がアプリケーション同一性を定義することになる。

欠落、不正な構文、矛盾した設定は、クエリ全体と順序を厳密に比べる既定値へ戻る。失うのはヒットであり、分離ではない。未知のDictionaryキーは無視されるため、将来拡張は同値範囲を広げる用途に限られる。範囲を狭める変更には、古い実装の過剰再利用を避ける別フィールドが必要だ。

見た目の文字列と比較入力は違う

同値性はscheme、host、port、pathを越えない。同一の境界内で非既定設定を使うと、WHATWGのapplication/x-www-form-urlencodedモデルでクエリを解析し、無視対象を除くかexceptだけを残し、必要ならキーで並べ替え、キーと値の組を比較する。重複キーは保持される。

percent decode、+から空白への変換、空要素の処理によって、外見の違う文字列が同じ組になる。無効なUTF-8がU+FFFDに変換され、異なるバイト列が一つのキーへ潰れる場合もある。一方、Unicode正規化は行わないため、NFCとNFDは別のままだ。

署名が元のバイト列を対象にし、ルーターが重複の順番を読み、空値が同意を表すなら、この差は脆弱性になる。草案も、form-urlencodedモデルでないクエリには有用でないとする。RFC 6943が示す識別子比較の問題は、ここでは保存済み応答の選択として実行される。

再利用は命令ではない

対応キャッシュは拡張照合を使えるが、使う義務はない。厳密キーを先に探してもよく、最新設定から簡略キーを作ってもよく、候補ヒットを辞退してもよい。オリジンの宣言は選択肢を与え、結果を引き受けるキャッシュが局所的な決定を保つ。

同じauthorityとpathの保存応答に異なる非空設定があれば、草案はより新しいDateの設定を優先して収束する方法を認める。新しさは意味の正しさではない。誤設定も最新になり得て、ローリング配備では各ノードの知識がずれる。

無効化規則も広がらない。状態変更要求の後、同値URIをまとめて無効化してよいが、必須ではない。読み取り時に同値だった保存物が、更新後には別々に残り得る。クエリを足すキャッシュバスターも、そのキーを無視すると機能しない。コンテンツハッシュを含むpathやfilenameは別の、より明示的な設計である。

URLにあるデータは消えない

ブラウザーは完全なURLを表示し履歴に残せる。CDNとproxyは識別子を受け取り、アクセスログや分析基盤も記録できる。No-Vary-Searchはキャッシュ照合の指定であり、リダイレクト、正規URL指定、匿名化ではない。

private cacheなら、二度目をローカルで返して追跡値をオリジンへ送らずに済む場合がある。shared cacheは要求を受け取り続け、誤設定なら一つの保存応答を渡す範囲まで広げる。「追跡パラメータを除去する」という説明は正確でない。

認可、本人性、署名検証、同意、ルーティング、監査、課金、失効、安全な再利用に必要な処理を左右するキーは、決して無視してはならない。同じ画像を返すワンタイムトークンでも、取得権限は同じではない。同じHTMLでも、監査イベントを省略できるとは限らない。

shared cacheの最悪例は、Bobのために取得した応答をAliceへ返すことだ。privateやpartitionは必要な防護だが、誤分類を正当化しない。オリジンは宣言に、キャッシュは実際の分離に責任を持つ。

オリジンへ届かなかった要求を証拠に残す

監査には、利用者が要求したURL、保存応答のURLと生フィールド、解析設定、変換後の比較組、選択されたentry、残るRFC 9111チェック、利用者とpartitionの文脈、hit/miss、origin bypass、配信bodyのfingerprintが必要だ。hit率だけでは、正しい同値性と効率的な漏えいを区別できない。

Lu Hengの最小の共通仕様と局所的な将来決定という整理では、共通層は小さな辞書と比較だけでよい。キー意味論はアプリケーションに残り、採用は各キャッシュの任意だ。running codeの優先は、設定値ではなく実際のentry選択と結果を検証するよう求める。

データ主権の技術面と実務面も分かれる。フィールドの形式的支配者はオリジンだが、URLはブラウザー、ログはCDN、bodyはキャッシュが保持し、二度目の要求をオリジンが見ないことさえある。ガバナンスはこの現実の保管関係を追う必要がある。

不確実ならmissを増やす。それは戻せる。利用者境界を一度越えた応答は戻せない。