インターネット技術標準化委員会 (IETF) P. Meenan、編集者
Request for Comments: 9842 Google LLC
カテゴリ: 標準化トラック Y. Weiss、編集者
ISSN: 2070-1721 Shopify Inc.
2025年9月

圧縮辞書の転送

概要

本文書は、ハイパーテキスト転送プロトコル（HTTP）における辞書ベースの圧縮のためのメカニズムを規定します。この手法を利用することで、クライアントとサーバーは送信データのサイズを削減でき、パフォーマンスの向上と帯域幅消費の低減が期待できます。本文書は既存の HTTP 圧縮方式を拡張し、圧縮辞書の配信と HTTP プロトコル内での利用に関するガイドラインを提供します。

このメモのステータス

これはインターネット標準化トラック文書です。

本書はインターネット技術標準化委員会（IETF）の成果物です。本書は IETF コミュニティの合意を表しており、公衆のレビューを受け、インターネット技術運営指導グループ（IESG）によって公開が承認されています。インターネット標準に関する詳細は RFC 7841 のセクション2 を参照してください。

本書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は https://www.rfc-editor.org/info/rfc9842 で入手できます。

Copyright Notice

Copyright (c) 2025 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 [HTTP] レスポンスを利用する仕組みを定義します。これは、外部辞書を利用可能な圧縮スキーム（例：Brotli [RFC7932] や Zstandard [ZSTD]）に対して適用されます。

この文書では、辞書使用のネゴシエーションに用いる HTTP ヘッダを説明し、交渉された辞書を用いた Brotli と Zstandard による圧縮のための content-encoding 値を登録します。

辞書使用のネゴシエーションは HTTP のコンテンツネゴシエーション（RFC 9110 Section 12）を活用しており、すべての HTTP バージョンで使用可能です。

1.1. ユースケース

任意の HTTP レスポンスは将来の HTTP リクエストの圧縮辞書として指定でき、これにより柔軟性が高まります。ここでは頻繁に見られる 2 つの一般的なユースケースを説明します。

1.1.1. バージョンアップグレード

古いバージョンのリソースを新しいバージョンの辞書として使用することで、差分圧縮（delta-compressed）された変更を配信でき、通常は圧縮のみで得られるものよりもはるかに小さいレスポンスになります。

例えば：

Client Server GET /app.v1.js 200 OK Use-As-Dictionary: match="/app*js" <full app.v1.js resource - 100KB compressed> Some time later ... Client Server GET /app.v2.js Available-Dictionary: :pZGm1A...2a2fFG4=: Accept-Encoding: gzip, br, zstd, dcb, dcz 200 OK Content-Encoding: dcb <delta-compressed app.v2.js resource - 1KB>

図1: バージョンアップグレードの例

1.1.2. 共通コンテンツ

複数のリソースがレスポンスに共通のパターンを持つ場合、それらの共通パターンを含む外部辞書を参照することでレスポンスからそれらを効果的に圧縮することが有用です。例としては、サイト内の類似ページ間で共通するテンプレート HTML や API コールで使われる共通のキーと値などがあります。

例えば：

Client Server GET /index.html 200 OK Link: <.../dict>; rel="compression-dictionary" <full index.html resource - 100KB compressed> GET /dict 200 OK Use-As-Dictionary: match="/*html" Some time later ... Client Server GET /page2.html Available-Dictionary: :pZGm1A...2a2fFG4=: Accept-Encoding: gzip, br, zstd, dcb, dcz 200 OK Content-Encoding: dcb <delta-compressed page2.html resource - 10KB>

図2: 共通コンテンツの例

1.2. 表記上の規約

本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、全て大文字で現れる場合に限り BCP 14 [RFC2119] および [RFC8174] に従って解釈されます。

本書では、構文と解析を指定するために RFC 9651 Section 3 の用語（Dictionary, String, Inner List, Token, Byte Sequence）を使用します。

本書はまた、長い行の折返し戦略として [FOLDING] で説明される手法を使用します。

さらに、本書は [HTTP] および [HTTP-CACHING] の用語も使用します。

2. 辞書のネゴシエーション

2.1. Use-As-Dictionary

サーバーは HTTP リクエストに応答する際、そのレスポンスが将来のリクエスト用の辞書として使用可能であることを、"Use-As-Dictionary" レスポンスヘッダで指定されたルールに一致する URL に対して広告することができます。

"Use-As-Dictionary" レスポンスヘッダは、"match"、"match-dest"、"id"、"type" の値を持つ Structured Field [STRUCTURED-FIELDS] の Dictionary です。

2.1.1. "match"

"Use-As-Dictionary" レスポンスヘッダの "match" 値は、リクエストのマッチングに使用する URL パターンを提供する String 値です（[URLPATTERN] を参照）。

マッチングに使用される URL パターンは正規表現をサポートしません。

次のアルゴリズムは、与えられた String 値が正規表現を使用せず、かつ辞書と同一オリジンの有効な URL パターンであるかを検証するために使用されます。有効なパターンであれば TRUE を、使用してはならない無効なパターンであれば FALSE を返します。

  1. 与えられた辞書の "match" の値を MATCH とする。

  2. 辞書リクエストの URL を URL とする。

  3. PATTERN を、input=MATCH および baseURL=URL として "create a URL pattern" の手順を実行して作成された "URL pattern struct" とする（URL Pattern Standard Section 1.4 を参照）。

  4. PATTERN に対して "has regexp groups" の手順を実行した結果が TRUE であれば FALSE を返す（同じく URL Pattern の該当箇所を参照）。

  5. TRUE を返す。

"match" 値は必須であり、辞書が有効と見なされるためには "Use-As-Dictionary" レスポンスヘッダに含まれていることが MUST です。

HTTP レベルで動作するため、指定されたマッチパターンは URL パスのパーセントエンコードされたバージョン上で動作します（RFC 3986 Section 2 を参照）。

例えば、URL "http://www.example.com/düsseldorf" は "http://www.example.com/d%C3%BCsseldorf" とエンコードされ、関連するマッチパターンは次のようになります：

Use-As-Dictionary: match="/d%C3%BCsseldorf"

2.1.2. "match-dest"

"Use-As-Dictionary" レスポンスヘッダの "match-dest" 値は、辞書がマッチする Fetch リクエストの destination のリストを提供する String 値の Inner List です（Fetch Standard Section 5.4 の "RequestDestination" を参照）。

"match-dest" が空リストである場合はすべての destination にマッチしなければなりません（MUST）。

リクエスト destination をサポートしないクライアントは、"match-dest" を空リストとして扱い、すべての destination にマッチさせること MUST です。

"match-dest" はオプションであり、デフォルトは空リストです。

2.1.3. "id"

"Use-As-Dictionary" レスポンスヘッダの "id" 値は、辞書のサーバー側識別子を指定する String 値です。"id" が存在し、その文字列長がゼロより大きい場合、クライアントは同じ辞書に対する "Available-Dictionary" リクエストを送るときに "Dictionary-ID" リクエストヘッダで保存した "id" をサーバーに送信しなければなりません（Section 2.2 を参照）。

サーバー識別子はクライアントによって不透明な文字列として扱われなければなりません（MUST）。

サーバーは識別子を辞書の内容を保証するものとして頼っては MUST NOT であり、辞書ハッシュは使用前に検証されなければなりません（MUST）。

"id" 値の文字列長（デコード後）は最大 1024 文字をサポートします。

"id" 値はオプションであり、デフォルトは空文字列です。

2.1.4. "type"

"Use-As-Dictionary" レスポンスヘッダの "type" 値は、提供された辞書のファイル形式を示す Token 値です。

"raw" は、任意の圧縮スキームが使用できる未加工のバイト列を表す辞書形式として定義されます。

クライアントが理解しないタイプの辞書を受け取った場合、クライアントはその辞書を使用しては MUST NOT です。

"type" 値はオプションであり、デフォルトは "raw" です。

2.1.5. 例

2.1.5.1. パスプレフィックス

次のようなレスポンスヘッダを含むレスポンスは、同一オリジン内で /product/ のパスプレフィックスを持つ任意のドキュメント要求に一致することを指定します（RFC 9110 Section 4.3.1 を参照）：

NOTE: '\' line wrapping per RFC 8792

Use-As-Dictionary: \
  match="/product/*", match-dest=("document")
2.1.5.2. バージョン化されたディレクトリ

次のようなレスポンスヘッダを含むレスポンスは、"/app/" で始まり "/main.js" で終わる任意のパスにマッチします：

Use-As-Dictionary: match="/app/*/main.js"

2.2. Available-Dictionary

クライアントが適切な辞書を保持しているリソースを要求する場合、リクエストに "Available-Dictionary" リクエストヘッダを追加して、圧縮に利用可能な辞書をサーバーに示すことができます。

"Available-Dictionary" リクエストヘッダは Structured Field [STRUCTURED-FIELDS] の Byte Sequence であり、単一の利用可能な辞書の内容に対する SHA-256 ハッシュ（[SHA-256]）を含みます。

クライアントは最良の利用可能な一致に対して単一のハッシュ値のみを含む単一の "Available-Dictionary" リクエストヘッダを送るべきであり、これを行うこと MUST です。

例えば：

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

2.2.1. 辞書の鮮度要件

一致と見なされるために、辞書リソースは新鮮であるか（[HTTP-CACHING]）、もしくは古くても提供可能であることが許容されなければなりません（[RFC5861] を参照）。

2.2.2. 辞書 URL の一致

"Use-As-Dictionary" 指示の結果として辞書が保存されると、それには "match" 文字列とオプションの "match-dest" 文字列が含まれ、これらはクライアントの発信リクエストを利用可能な辞書と照合するために使用されます。

送信リクエストが与えられた辞書に一致するかを確認するために、次のアルゴリズムは成功した一致であれば TRUE を、そうでなければ FALSE を返します：

  1. 現在のクライアントがリクエスト destination をサポートしており、辞書に "match-dest" 文字列が提供されている場合：

    • DEST をその辞書の "match-dest" の値とする。

    • REQUEST_DEST を現在のリクエストの destination の値とする。

    • もし DEST が空リストでなく、かつ REQUEST_DEST が DEST のリストに含まれていなければ FALSE を返す。

  2. BASEURL を辞書リクエストの URL とする。

  3. URL をチェック対象の発信リクエストの URL とする。

  4. BASEURL のオリジンと URL のオリジンが同じでない場合、FALSE を返す（RFC 9110 Section 4.3.1 を参照）。

  5. MATCH をその辞書の "match" の値とする。

  6. PATTERN を、input=MATCH および baseURL=URL として "create a URL pattern" の手順を実行して作成された "URL pattern struct" とする（URLPATTERN Section 1.4 を参照）。

  7. PATTERN に対して "match" の手順を input=URL で実行した結果を返す。これによりリクエスト URL と提供された "match" 文字列のマッチを確認する（URLPATTERN の該当箇所を参照）。

2.2.3. 複数の一致する辞書

あるリクエスト URL に一致する複数の辞書が存在する場合、クライアントは次のルールに従って単一の辞書を選択しなければなりません（MUST）。

  1. リクエスト destination をサポートするクライアントでは、"match-dest" を指定し一致する辞書が、destination を使用しない一致より優先されます。

  2. 上記の destination の優先度が同等であれば、"match" が最も長い辞書が優先されます。

  3. destination と match 長さが同等であれば、最も最近取得された辞書が優先されます。

2.3. Dictionary-ID

クライアントが適切な辞書を保持しており、その辞書が "Use-As-Dictionary" レスポンスヘッダでサーバー提供の "id" とともに保存された場合、クライアントは将来のリクエストで保存した "id" を "Dictionary-ID" リクエストヘッダとしてエコーすること MUST です。

"Dictionary-ID" リクエストヘッダは Structured Field [STRUCTURED-FIELDS] の String で、デコード後最大 1024 文字まで許容され、サーバー提供の "id" と同一であること MUST です。

例えば、次のような辞書 ID を設定した HTTP レスポンスがあった場合：

Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"

その後の一致するリクエストは、ハッシュと ID の両方を含みます：

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345"

4. 辞書圧縮 Brotli

"dcb" コンテンツエンコーディングは "Dictionary-Compressed Brotli" ストリームを識別します。

"Dictionary-Compressed Brotli" ストリームは固定ヘッダに続いて Shared Brotli [SHARED-BROTLI] ストリームが続く形式です。ヘッダは 4 バイトの固定シーケンスと、使用された外部辞書の 32 バイトハッシュで構成されます。Shared Brotli ストリームは参照された外部辞書と、最大 16 MB の圧縮ウィンドウを使用して作成されます。

"dcb" コンテンツエンコーディングで使用される辞書は Section 2.1.4 の "raw" 辞書タイプであり、[SHARED-BROTLI] の Section 8.2 で定義されるプレフィックス辞書として扱われます。

36 バイトの固定ヘッダは次のとおりです：

Magic_Number:
4 バイト固定 -- 0xff, 0x44, 0x43, 0x42.
SHA_256_Hash:
32 バイト。辞書の SHA-256 ハッシュダイジェスト（[SHA-256]）。

dcb コンテンツエンコーディングをサポートすると宣言するクライアントは、最大 16 MB のウィンドウサイズで圧縮されたリソースを復号できる必要があります（MUST）。

Brotli 圧縮では、圧縮および復号の両方で辞書全体が圧縮ウィンドウに依存せず利用可能であり、圧縮ウィンドウより大きなリソースの差分圧縮が可能です。

5. 辞書圧縮 Zstandard

"dcz" コンテンツエンコーディングは "Dictionary-Compressed Zstandard" ストリームを識別します。

"Dictionary-Compressed Zstandard" ストリームは 40 バイトの固定ヘッダで始まり、その後に外部辞書で圧縮された Zstandard [ZSTD] ストリームが続くバイナリストリームです。

"dcz" で使用される辞書は Section 2.1.4 の "raw" 辞書タイプであり、[ZSTD] の Section 5 に従う raw 辞書として扱われます。

40 バイトヘッダは、8 バイトの固定シーケンスに続いて使用された外部辞書の 32 バイト SHA-256 ハッシュで構成されます。

Magic_Number:
8 バイト固定 -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.
SHA_256_Hash:
32 バイト。辞書の SHA-256 ハッシュダイジェスト（[SHA-256]）。

40 バイトヘッダは Zstandard のスキップ可能フレーム（リトルエンディアン 0x184D2A5E）で、32 バイト長（リトルエンディアン 0x00000020）を持ち、既存の Zstandard デコーダと互換性があります。

dcz コンテンツエンコーディングをサポートすると宣言するクライアントは、少なくとも 8 MB または辞書サイズの 1.25 倍のいずれか大きい方、最大 128 MB までのウィンドウサイズで圧縮されたリソースを復号できる必要があります（MUST）。

使用されるウィンドウサイズはコンテンツ内にエンコードされ（現時点では 2 の冪でしか表現できない）、この上限を超えてはならない（MUST）。実装は、制限を超えるウィンドウサイズを復号エラーとして扱ってもよい（MAY）。

Zstandard 圧縮では、入力サイズが圧縮ウィンドウを超えるまでは圧縮と復号の両方で辞書全体が利用可能です。その点を越えると辞書は利用不能になります。辞書サイズの 1.25 倍の圧縮ウィンドウを使用することで、リリース間でリソースが 25% 増大した場合でも差分圧縮を完全に行うことができ、クライアントが特定のレスポンスに必要とするメモリ量を制御できます。

6. コンテンツエンコーディングのネゴシエーション

特定のリクエストのレスポンスを圧縮するために圧縮辞書が利用可能な場合、使用するエンコーディングは "Accept-Encoding" リクエストヘッダと "Content-Encoding" レスポンスヘッダを通じて HTTP の通常のメカニズムでネゴシエートされます。

使用する辞書は別個にネゴシエートされ、"Available-Dictionary" リクエストヘッダで広告されます。

6.1. Accept-Encoding

あるリクエストで辞書が使用可能であり、クライアントが辞書ベースのコンテンツエンコーディングを利用可能にすることを選択した場合、クライアントはサポートする辞書対応コンテンツエンコーディングを "Accept-Encoding" リクエストヘッダに追加します。例えば：

Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz

クライアントがリクエストに一致する保存済み辞書を持っていないか、そのリクエストで辞書を使用しないことを選択した場合、クライアントは辞書対応のコンテンツエンコーディングを "Accept-Encoding" リクエストヘッダに送っては MUST NOT です。

6.2. Content-Encoding

サーバーがクライアントが広告した辞書対応エンコーディングのいずれかをサポートし、かつクライアントが広告した辞書を用いてレスポンスのコンテンツを圧縮することを選択した場合、サーバーは選択したアルゴリズムに対応する値で "Content-Encoding" レスポンスヘッダを設定します。例えば：

Content-Encoding: dcb

レスポンスがキャッシュ可能な場合、キャッシュが辞書対応をサポートしないクライアントに辞書圧縮されたリソースを提供したり、誤った辞書で圧縮されたレスポンスを提供したりしないように、レスポンスは "Vary" ヘッダを含めなければなりません（MUST）。例えば：

Vary: accept-encoding, available-dictionary

7. IANA に関する考慮事項

7.1. コンテンツエンコーディングの登録

IANA は、以下のエントリを "HTTP Content Coding Registry"（https://www.iana.org/assignments/http-parameters/）に追加しました：

Name:
dcb
Description:
"Dictionary-Compressed Brotli" データ形式。
Reference:
RFC 9842, Section 4
Name:
dcz
Description:
"Dictionary-Compressed Zstandard" データ形式。
Reference:
RFC 9842, Section 5

7.2. ヘッダーフィールドの登録

IANA は、次のエントリを "Hypertext Transfer Protocol (HTTP) Field Name Registry"（https://www.iana.org/assignments/http-fields/）に追加しました：

Table 1
Field Name Status Reference
Use-As-Dictionary permanent RFC 9842, Section 2.1
Available-Dictionary permanent RFC 9842, Section 2.2
Dictionary-ID permanent RFC 9842, Section 2.3

8. 互換性に関する考慮事項

ネットワーク経路上に HTTP リクエストを傍受、検査、処理するデバイス（ウェブプロキシ、ファイアウォール、侵入検知システム等）が存在することは珍しくありません。これらのデバイスが辞書圧縮されたレスポンスを誤って処理するリスクを最小化するために、圧縮辞書の転送は MUST HTTPS のような安全なコンテキストでのみ使用すべきです。

9. セキュリティに関する考慮事項

Brotli ([RFC7932]), Shared Brotli ([SHARED-BROTLI]), および Zstandard ([ZSTD]) に関するセキュリティ考慮事項は、それぞれのアルゴリズムの辞書ベース版にも適用されます。

9.1. コンテンツの変更

辞書はコンテンツと同じセキュリティ上の注意を払って扱う必要があります。なぜなら辞書の変更は展開後のデータに影響を与え得るためです。

辞書は内容の SHA-256 ハッシュを用いて検証され、クライアントとサーバーが同じ辞書を使用していることを確認します。辞書ネゴシエーションで異なるハッシュアルゴリズムを使うべきと判断される場合、"Use-As-Dictionary" レスポンスヘッダを拡張して別のアルゴリズムを指定することができ、サーバーは更新されたハッシュを使用しない "Available-Dictionary" リクエストを無視します。

9.2. コンテンツの読み取り

RFC 7457 Section 2.6 に示される圧縮に関する攻撃は、混在したデータ（公開データと機密データなど）を圧縮することが悪い考えであることを示しています。ここでのデータソースには圧縮データだけでなく辞書も含まれます。例えば、秘密のクッキーが公開データ専用の辞書で圧縮される場合でも、クッキーに関する情報が漏れる可能性があります。

辞書は圧縮データについて情報を明らかにし得るし、その逆もまた然りです。つまり、攻撃者が圧縮対象の一部を制御して圧縮後のサイズを観察できる場合、辞書の内容を暴露できる可能性があります。一方、攻撃者が辞書を制御できる場合、圧縮データから情報を学習することが可能です。

9.3. セキュリティ緩和策

いずれかの緩和策が満たされない場合、クライアントはレスポンスを破棄してエラーを返さなければなりません（MUST）。

9.3.1. クロスオリジン保護

辞書が提供されたオリジンと同じオリジンのコンテンツにのみ影響を与えるようにするため、辞書をリクエストにマッチさせるために使う URL パターン（Section 2.1.1 を参照）は、辞書が提供されたオリジンのものに限定されています。

9.3.2. レスポンスの可読性

ブラウザのようにレスポンスのペイロード可読性やユーザートラッキングに対する追加保護を提供するクライアントでは、辞書ベースの圧縮が元来得られるであろう情報を露呈しないように、追加の保護措置を講じること MUST です。

このような場合、辞書圧縮は辞書と圧縮されたレスポンスの両方がクライアントによって完全に可読であるときにのみ使用しては MUST です。

ブラウザの用語では、辞書と圧縮レスポンスがフェッチ元のコンテキストと同一オリジンであるか、またはレスポンスがクロスオリジンで CORS チェックを通過している必要があります（Fetch Standard Section 4.9 の CORS チェックを参照）。

9.3.3. サーバーの責任

安全なコンテキストで圧縮コンテンツを使用する際には、攻撃者が辞書の一部を制御したり辞書を読み取りつつ圧縮対象の一部を制御して複数のリクエストを行える場合に、潜在的なタイミング攻撃が存在します。そのような攻撃では、レスポンスのサイズや処理時間の変化がコンテンツに関する情報を漏らす可能性があります。

一般に、サーバーは同一コンテンツに対して複数の辞書を能動的に使用することを防いだり、コンテンツの一部が制御されている場合は圧縮を無効化したり、辞書コンテンツへのアクセスと制御をレスポンスコンテンツと同様に保護することでこれらの攻撃を緩和できます。加えて、以下の要件はクライアントがクロスオリジンのリクエストコンテキストを示す CORS リクエストヘッダを提供した場合に、サーバーが辞書対応圧縮を無効化することを目的としています。

次のアルゴリズムは、CORS 保護などの予防措置が検討されるべきクロスオリジンリクエストに対して FALSE を返します：

  1. "Sec-Fetch-Site" リクエストヘッダが存在しない場合、TRUE を返す。

  2. "Sec-Fetch-Site" リクエストヘッダの値が "same-origin" の場合、TRUE を返す。

  3. "Sec-Fetch-Mode" リクエストヘッダが存在しない場合、TRUE を返す。

  4. "Sec-Fetch-Mode" の値が "navigate" または "same-origin" の場合、TRUE を返す。

  5. "Sec-Fetch-Mode" の値が "cors" の場合：

    • レスポンスが "Access-Control-Allow-Origin" レスポンスヘッダを含まない場合、FALSE を返す。

    • リクエストが "Origin" リクエストヘッダを含まない場合、FALSE を返す。

    • "Access-Control-Allow-Origin" レスポンスヘッダの値が "*" の場合、TRUE を返す。

    • "Access-Control-Allow-Origin" レスポンスヘッダの値が "Origin" リクエストヘッダの値と一致する場合、TRUE を返す。

  6. FALSE を返す。

10. プライバシーに関する考慮事項

辞書は将来のリクエストで辞書の内容のハッシュを使って広告されるため、辞書を追跡クッキーに悪用することが可能です。

追加のトラッキング懸念を軽減するため、クライアントは辞書をクッキーと同様に扱わなければなりません（MUST）。これには、クッキーに対して使用されるのと同等かそれより厳格なパーティショニングを用いて保存を分割し、クッキーが消去されたときに辞書も消去することが含まれます。

11. 参考文献

11.1. 規範的参考文献

[FETCH]
WHATWG, “Fetch Standard”, WHATWG Living Standard, <https://fetch.spec.whatwg.org/>.
Commit snapshot: <https://fetch.spec.whatwg.org/commit-snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>.
[FOLDING]
Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.
[HTTP-CACHING]
Fielding, R., Nottingham, M., and J. Reschke, “HTTP Caching”, RFC 9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTP]
Fielding, R., Nottingham, M., and J. Reschke, “HTTP Semantics”, RFC 9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA-256]
Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, RFC 6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[SHARED-BROTLI]
Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z., and L. Vandevenne, Ed., “Shared Brotli Compressed Data Format”, RFC 9841, September 2025, <https://www.rfc-editor.org/info/rfc9841>.
[STRUCTURED-FIELDS]
Nottingham, M. and P-H. Kamp, “Structured Field Values for HTTP”, RFC 9651, September 2024, <https://www.rfc-editor.org/info/rfc9651>.
[URLPATTERN]
WHATWG, “URL Pattern Standard”, WHATWG Living Standard, <https://urlpattern.spec.whatwg.org/>.
Commit snapshot: <https://urlpattern.spec.whatwg.org/commit-snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/>.
[URL]
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[WEB-LINKING]
Nottingham, M., “Web Linking”, RFC 8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[ZSTD]
Collet, Y. and M. Kucherawy, Ed., “Zstandard Compression and the 'application/zstd' Media Type”, RFC 8878, February 2021, <https://www.rfc-editor.org/info/rfc8878>.

11.2. 参考情報

[RFC5861]
Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”, RFC 5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.
[RFC6265]
Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC7457]
Sheffer, Y., Holz, R., and P. Saint-Andre, “Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)”, RFC 7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7932]
Alakuijala, J. and Z. Szabadka, “Brotli Compressed Data Format”, RFC 7932, July 2016, <https://www.rfc-editor.org/info/rfc7932>.

Authors' Addresses

Patrick Meenan (editor)
Google LLC
EMail: pmeenan@google.com
Yoav Weiss (editor)
Shopify Inc.
EMail: yoav.weiss@shopify.com