No-Vary-Search HTTP キャッシュ拡張

本文書のステータス

このインターネットドラフトは、 BCP 78 および BCP 79 の規定に完全に準拠して提出されている。¶

インターネットドラフトは、Internet Engineering Task Force（IETF）の作業文書である。他のグループも作業文書を インターネットドラフトとして配布する場合があることに注意されたい。 現在のインターネットドラフトの一覧は https://datatracker.ietf.org/drafts/current/ にある。¶

インターネットドラフトは最大 6 か月間有効なドラフト文書であり、 いつでも他の文書によって更新、置換、または廃止される可能性がある。 インターネットドラフトを参考資料として用いること、または 「作業中」のものとして以外に引用することは不適切である。¶

このインターネットドラフトは 2027年1月2日に失効する。¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

目次

1. 序論

HTTP キャッシュ [HTTP-CACHING] は、多数のキャッシュキーにわたって一致するリソースを再利用することに基づいており、その中で最も重要なものは 提示された対象 URI（Section 7.1 of [HTTP]）です。しかし、 複数の URI が同じリソースを表す場合があります。これにより、キャッシュは常に本来ほど 有用であるとは限りません。すなわち、キャッシュにある URI の下でレスポンスが含まれていても、その後 別の URI の下でレスポンスが要求されると、キャッシュされた版は無視されます。¶

"No-Vary-Search" レスポンスヘッダーフィールドは、 Section 4 of [HTTP-CACHING] で説明されるキャッシュ拡張を定義し、 この一般的な問題の特定の部分集合、すなわち特定のクエリパラメータのみが異なる別々の URI が 同じリソースを識別する場合に対処します。これは、クエリコンポーネントの一部または全部が、 提供されるレスポンスに意味的に影響しないため、キャッシュ照合の目的では無視できることを リソースが宣言できるようにします。たとえば、クエリパラメータの順序が、どのリソースが 識別されるかに影響しない場合、これは次を使用して示されます¶

No-Vary-Search: key-order

特定のクエリパラメータ（例: 分析用に何かを示すもの）が 提供されるリソースに意味的に影響しない場合、これは次を使用して示されます¶

No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign")

そして、リソースが代わりに許可リストベースのアプローチを取り、 既知の特定のクエリパラメータだけが提供されるレスポンスに意味的に影響するようにしたい場合、 次を使用できます¶

No-Vary-Search: except=("productId")

キャッシュされたレスポンスの取得を避けるために一意なクエリパラメータを送る 「キャッシュバスティング」は、No-Vary-Search ヘッダーフィールドによって 無効化される場合があることに注意してください。¶

Section 3 は、 [STRUCTURED-FIELDS] フレームワークを使用して、 新しいレスポンスヘッダーフィールド No-Vary-Search を定義します。Section 4 および Section 5 は、フィールド値を仕様でどのように表現できるかについてのデータモデルと、 structured field パーサーからの生の出力をそのデータモデルへ解析するプロセスを示します。Section 6 は、ヘッダーフィールドの影響下で 2 つの URL が等価かどうかを比較するための主要なアルゴリズムを示します。特に、これは [WHATWG-URL] で指定される application/x-www-form-urlencoded 形式によって与えられる クエリコンポーネントのキーと値への分解に依存しています。（したがって、このヘッダーフィールドは、 その形式に従わないクエリコンポーネントを持つ URL には有用ではありません。）最後に、Section 7 は、この新しい等価性を考慮に入れるために Section 4 of [HTTP-CACHING] を拡張する方法を説明します。¶

2. 規約と定義

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" は、 ここに示されるようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されるように解釈されます。¶

この文書では、"URI" と "URL" という用語は、文脈に応じて 同じ意味で使用されます。"URI" は [URI], [HTTP], および [HTTP-CACHING] の文脈で使用され、 一方 "URL" は [WHATWG-URL] で指定される アルゴリズムの文脈で使用されます。¶

この文書はまた、WHATWG および W3C の用法で典型的な規約や記法も採用します。 特にアルゴリズムに関係するものです。[WHATWG-INFRA]、とりわけ以下を参照してください:¶

• リストの定義。リストリテラル記法 « 1, 2, 3 » を含みます。¶

• 文字列の定義。コード単位としての表現を含みます。¶

（使用される他の概念はインライン参照を使用して示されます。）¶

3. HTTP ヘッダーフィールド定義

No-Vary-Search HTTP ヘッダーフィールドは structured field [STRUCTURED-FIELDS] であり、その値は 辞書（Section 3.2 of [STRUCTURED-FIELDS]）で MUST あります。¶

これは次のオーサリング適合要件を持ちます:¶

• 存在する場合、key-order エントリの値は boolean（Section 3.3.6 of [STRUCTURED-FIELDS]）で MUST あります。¶

• 存在する場合、params エントリの値は文字列の inner list（Section 3.1.1 of [STRUCTURED-FIELDS]）で MUST あります。¶

• 存在する場合、except エントリの値は文字列の inner list（Section 3.1.1 of [STRUCTURED-FIELDS]）で MUST あります。¶

• params エントリも存在する場合、 except エントリは存在しては MUST NOT なりません。¶

辞書は、key-order, params, および except の いずれでもないキーを持つエントリを含んでも MAY よいですが、それらの意味は この仕様では定義されません。この仕様の実装はそのようなエントリを無視します（ただし将来の文書が そのようなエントリに意味を割り当てる可能性があります）。¶

4. データモデル

URL variation config は次で構成されます:¶

no-vary params

特殊値 wildcard または文字列のリスト¶

vary params

特殊値 wildcard または文字列のリスト¶

vary on key order

boolean¶

default URL variation config は、no-vary params が空リスト、vary params が wildcard、vary on key order が true である URL variation config です。¶

obtain a URL variation config アルゴリズム（Section 5.2）は、 すべての URL variation configs が次の制約に従うことを保証します:¶

• vary params がリストであることと、no-vary params が wildcard であることは同値です。そして¶

• no-vary params がリストであることと、vary params が wildcard であることは同値です。¶

5. 解析

No-Vary-Search: params=("%C3%A9+%E6%B0%97")

6. 比較

2 つの URLs [WHATWG-URL] urlA および urlB は、 URL variation config variationConfig が与えられたとき、次のアルゴリズムが true を返すなら equivalent modulo variation config です:¶

1. urlA と urlB の scheme、username、password、host、port、または path が 異なる場合、false を返す。¶

2. variationConfig が default URL variation config と 等価である場合:¶

   1. urlA の query が urlB の query と等しい場合、 true を返す。¶

   2. false を返す。¶

   この場合、クエリに対して application/x-www-form-urlencoded parser [WHATWG-URL] を実行した後では 同じように見える可能性のある URL ペアであっても、たとえば https://example.com/a と https://example.com/a?、または https://example.com/foo?a=b&&&c と https://example.com/foo?a=b&c= は、非等価として扱われます。¶

3. searchParamsA および searchParamsB を空リストとする。¶

4. urlA の query が null でない場合、 searchParamsA を、urlA の query の isomorphic encoding [WHATWG-INFRA] が与えられて application/x-www-form-urlencoded parser [WHATWG-URL] を実行した 結果に設定する。¶

5. urlB の query が null でない場合、 searchParamsB を、urlB の query の isomorphic encoding [WHATWG-INFRA] が与えられて application/x-www-form-urlencoded parser [WHATWG-URL] を実行した 結果に設定する。¶

6. variationConfig の no-vary params がリストである場合:¶

   1. searchParamsA を、 searchParamsA 内の item pair のうち、 variationConfig の no-vary params が pair[0] を含まないものを含むリストに設定する。¶

   2. searchParamsB を、 searchParamsB 内の item pair のうち、 variationConfig の no-vary params が pair[0] を含まないものを含むリストに設定する。¶

7. そうでなく、variationConfig の vary params がリストである場合:¶

   1. searchParamsA を、 searchParamsA 内の item pair のうち、 variationConfig の vary params が pair[0] を含むものを含むリストに設定する。¶

   2. searchParamsB を、 searchParamsB 内の item pair のうち、 variationConfig の vary params が pair[0] を含むものを含むリストに設定する。¶

8. variationConfig の vary on key order が false である場合:¶

   1. keyLessThan を、2 つの pairs（keyA, valueA）および（keyB, valueB）を 入力として取り、keyA が keyB より code unit less than [WHATWG-INFRA] であるかどうかを返すアルゴリズムとする。¶

   2. searchParamsA を、 keyLessThan によって昇順に ソート [WHATWG-INFRA] した結果に設定する。¶

   3. searchParamsB を、 keyLessThan によって昇順に ソート [WHATWG-INFRA] した結果に設定する。¶

9. searchParamsA の size が searchParamsB の size と等しくない場合、false を返す。¶

10. i を 0 とする。¶

11. i < searchParamsA の size の間:¶

    1. searchParamsA[i][0] が searchParamsB[i][0] と等しくない場合、false を返す。¶

    2. searchParamsA[i][1] が searchParamsB[i][1] と等しくない場合、false を返す。¶

    3. i を i + 1 に設定する。¶

12. true を返す。¶

7. キャッシュ

キャッシュ [HTTP-CACHING] が この仕様を実装する場合、Section 4 of [HTTP-CACHING] における 提示された対象 URI 要件:¶

提示された対象 URI（[HTTP] の Section 7.1）と保存されたレスポンスのそれが一致し、かつ¶

は次に置き換えられます:¶

提示された対象 URI（[HTTP] の Section 7.1）と保存されたレスポンスのそれが一致するか、 URL variation config を法として等価であり、かつ¶

キャッシュ実装は、target URI が URL variation config を法として のみ 一致する保存レスポンスの再利用に失敗しても MAY よいです。ただし、そのキャッシュがより最近に、次を満たすレスポンスを 保存している場合です:¶

• query を除いて、提示された対象 URI と等しい target URI を持ち、かつ¶

• No-Vary-Search field に空でない値を持ち、かつ¶

• 再利用を検討している保存レスポンスとは異なる No-Vary-Search field value を持つ。¶

キャッシュ実装の効率を助けるため、サーバーは、query component の処理方法を 更新する必要がない限り、ある pathname へのリクエストに対するレスポンスで、 No-Vary-Search field に対して時とともに異なる空でない値を送信すべきでは SHOULD NOT ありません。そうすると、上記のような戦略を使用するキャッシュ実装が、 本来再利用できた一部の保存レスポンスを見逃すことになります。¶

8. セキュリティ上の考慮事項

注意すべき主なリスクは、一致しない URL の影響です。特に、これは、 ユーザーがリンクにホバーしたときに表示された URL、または URL バーに表示された URL とは異なる URL から元々取得されたレスポンスをユーザーが見ることにつながる可能性があります。¶

しかし、影響はクエリパラメータに限定されるため、これは関連する セキュリティ境界である origin [HTML] を越えません。（または、ウェブブラウザの セキュリティ UI の観点 からは、 単に host かもしれません。 [WHATWG-URL]）実際、私たちはすでに origin に対し、history.replaceState() や service workers のような技術によるクライアント側も含めて、（URL, response body）ペアを どのように提示するかについて完全な制御を与えています。¶

9. プライバシー上の考慮事項

この提案は、ユーザー識別子を渡すためにクエリパラメータをよく使用する navigational tracking という、プライバシーに非常に関連する領域に隣接しています。しかし、この提案自体には プライバシーへの影響はないと考えます。これは 既存の navigational tracking mitigations、または検討されている既知の将来のものに干渉しません。 実際、ページがその URI にユーザー識別子をエンコードする場合、この提案が与える唯一の能力は、 サーバーによるそのようなユーザー ID の処理を防ぐ（サーバーがキャッシュのために迂回される）ことによって、 そのようなユーザートラッキングを減らすことです。[NAV-TRACKING-MITIGATIONS]¶

10. IANA に関する考慮事項

11. 参考文献

謝辞

この文書は、次の方々による有益なレビューと提案から恩恵を受けました:¶

• Adam Rice¶

• Julian Reschke¶

• Kevin McNee¶

• Liviu Tinta¶

• Mark Nottingham¶

• Martin Thomson¶

• Valentin Gosu¶

著者の連絡先