メインコンテンツまでスキップ

RFC 8941 - Structured Field Values for HTTP (HTTP構造化フィールド値)

発行日: 2021年2月
ステータス: 標準化過程 (Standards Track)
著者: M. Nottingham (Fastly), P-H. Kamp (The Varnish Cache Project)

概要 (Abstract)​

本文書は、HTTPヘッダー (header) およびトレイラー (trailer) フィールドの定義と処理をより簡単かつ安全にすることを目的とした一連のデータ型と関連アルゴリズムを記述します。これらは「構造化フィールド (Structured Fields)」、「構造化ヘッダー (Structured Headers)」または「構造化トレイラー (Structured Trailers)」と呼ばれます。本文書は、従来のHTTPフィールド値よりも厳格な共通構文を使用したい新しいHTTPフィールド仕様での使用を意図しています。

本メモのステータス (Status of This Memo)​

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

本文書はインターネット技術特別調査委員会 (IETF) の成果物です。IETFコミュニティの合意を表しています。公開レビューを受け、インターネット技術運営委員会 (IESG) による発行の承認を得ています。インターネット標準の詳細については、RFC 7841のセクション2を参照してください。

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

目次 (Table of Contents)​

付録 (Appendices)​

核心概念クイックリファレンス (Quick Reference)​

3つのトップレベルデータ型​

1. List (リスト)          - 項目の順序付きシーケンス
2. Dictionary (辞書)      - キーと値のペアの順序付きマッピング
3. Item (項目)           - 単一の値

6つの基本データ型​

1. Integer (整数)        - 範囲: -999,999,999,999,999 ～ 999,999,999,999,999
2. Decimal (小数)        - 最大3桁の小数
3. String (文字列)       - 二重引用符で囲まれたテキスト
4. Token (トークン)      - 引用符なしの識別子
5. Byte Sequence (バイトシーケンス) - Base64エンコードされたバイナリデータ
6. Boolean (真偽値)      - ?1 (true) または ?0 (false)

例​

List (リスト)​

Example-List: "foo", "bar", baz
Example-List: 1, 2, (a b c)

Dictionary (辞書)​

Example-Dict: a=1, b=2
Example-Dict: key="value", flag

Item (項目)​

Example-Integer: 42
Example-String: "hello world"
Example-Token: application/json
Example-Boolean: ?1

重要性​

RFC 8941は現代のHTTPインフラストラクチャの中核仕様であり、以下で広く使用されています:

1. HTTP/2とHTTP/3のヘッダー​

  • 多くの新しいHTTPヘッダーが構造化フィールド形式を使用
  • より効率的なバイナリエンコーディング

2. Client Hints (RFC 8942)​

Sec-CH-UA: "Chromium";v="93", " Not;A Brand";v="99"
Sec-CH-Viewport-Width: 1024
Sec-CH-DPR: 2

3. CDNとキャッシュ制御​

CDN-Cache-Control: max-age=3600, s-maxage=7200

4. 現代のWeb機能​

  • Cross-Origin Resource Policy (CORP)
  • Cross-Origin Embedder Policy (COEP)
  • 多くのセキュリティ関連ヘッダー

なぜ構造化フィールドが必要なのか？​

従来のHTTPヘッダーの問題​

# 異なるフィールドが異なる構文を使用:
Cache-Control: max-age=3600, private
Accept: text/html, application/json;q=0.9
Link: `https://example.com`; rel="preload"

# 各フィールドにカスタムパーサーが必要
# エラーが発生しやすく、メンテナンスが困難

構造化フィールドの利点​

# 統一された構文とパースルール
Structured-Header: a=1, b=2, c=(x y z)

# 利点:
✓ 標準化されたデータ型
✓ 明確なパースアルゴリズム
✓ より良い相互運用性
✓ 将来の最適化をサポート (HTTP/3のバイナリエンコーディングなど)

設計原則​

1. 意図的な厳格性​

  • パース失敗時は即座にエラー、「修復」を試みない
  • 曖昧さとセキュリティ問題を回避
  • 相互運用性を促進

2. 将来互換性​

  • 抽象データモデルとシリアライゼーションを分離
  • 将来、より効率的なシリアライゼーション方式を定義可能

3. 実用性優先​

  • 既存のHTTPフィールドの実践経験に基づく
  • 表現力と複雑さのバランス

クイック例​

新しい構造化ヘッダーの定義​

"Example-Priorities" ヘッダーを定義するとします:

仕様定義:
-----------
Example-Priorities ヘッダーは構造化フィールド (Structured Field) です。
その値は辞書 (Dictionary) でなければなりません。
辞書のキーはリソース識別子 (token)、値は優先度 (integer) です。

例:
-----
Example-Priorities: css=10, js=5, images=1

パースと使用​

// 疑似コード例
const header = "css=10, js=5, images=1";
const dict = parseDictionary(header);

console.log(dict.get('css'));    // 10
console.log(dict.get('js'));     // 5
console.log(dict.get('images')); // 1

対象読者​

  • HTTP仕様作成者: 新しいHTTPヘッダーを定義する際に使用
  • ブラウザ実装者: パースとシリアライゼーションアルゴリズムの実装
  • CDNとプロキシ開発者: 現代のHTTPヘッダーの処理
  • Web開発者: 現代のHTTPヘッダー形式の理解
に最終更新