[47] HTTPメッセージのヘッダー部header sectionは、 HTTPヘッダーを記述できる部分です。

仕様書

ヘッダー部

[7] HTTPメッセージのうち0個以上の頭欄の部分のことを、 頭部header sectionやヘッダー群headersといいます >>6。

[8] >>7 の定義によると開始行は頭部には含まれていません。 トレーラー部もヘッダー部の一部では無さそうです。

[9] 頭部のそれぞれの項目のことを仕様上は頭欄、一般的にはヘッダーと呼んでいます。 頭部のことをヘッダー群と言うのはこのヘッダーという呼称に由来します。 HTTP に影響を与えた RFC 822 の本来の用語では、 頭部全体のことをヘッダーheaderと呼んでいました。

ヘッダーリスト

[5] Fetch >>3 と HTTP/2 >>73 や HPACK >>4 は、 0個以上のヘッダーの順序付きのリストをヘッダーリストheader listと呼んでいます。

[10] HTTP/2 や HPACK では、トレーラー部も (独立した) ヘッダーリストです。

HTTP/1.x ヘッダー部

[31] 仕様上の長さ制限はありません。

[30] Chrome はヘッダー部の末尾の CRLF までが 218-1 バイト (= 256KB-1B) 以下に収まっていなければならないようです。そうでなければ非文書表示でエラーとなります。 IE や Firefox は数MBより大きくても大丈夫なようです。制限があるのかは不明です。

[39] サーバーは、大きすぎる時 431 応答を返すことができます。

[35] 個別のヘッダーについては、HTTPヘッダーを参照。

[37] 構文解析については、HTTPメッセージやHTTPの構文解析を参照。

HTTP/2 ヘッダー

[12] HTTP/2 では、HTTPメッセージの先頭となる1つ以上のフレームにより、 ヘッダーリストが転送されます。

[13] 加えて、HTTPメッセージの末尾となる1つ以上のフレームにより、 トレーラー部のヘッダーリストが転送されます。

[99] HTTP/2 のヘッダーには、 HTTP/1.1 と共通の通常の HTTPヘッダーの他に、 HTTP/1.1 の開始行に相当する疑似ヘッダーがあります。

[14] 疑似ヘッダーは、通常のヘッダーより前になければなりません >>92。

[15] 疑似ヘッダーはtrailerでは使えません >>92。

[16] ヘッダー名、ヘッダー値も参照。

構文

[77] ヘッダーを表すフレーム群は、 HEADERS または PUSH_PROMISE で始まり、0個以上の CONTINUATION が続きます >>73, >>29。

[25] 最後のフレームでは END_HEADERS (0x4 = 第2ビット) フラグが設定され、それ以外のフレームでは設定されません >>73, >>24, >>26, >>29。

  1. |
    1. HEADERS (END_HEADERS)
    2. PUSH_PROMISE (END_HEADERS)
    3. =
      1. |
        1. HEADERS (¬END_HEADERS)
        2. PUSH_PROMISE (¬END_HEADERS)
      2. *
        1. CONTINUATION (¬END_HEADERS)
      3. CONTINUATION (END_HEADERS)

[17] 通常の HTTPメッセージのヘッダー部やトレーラー部では、 HEADERS フレームを使います。 サーバープッシュの要求のヘッダー部では、 PUSH_PROMISE フレームを使います。

[80] ヘッダーブロックは連続したフレームとして転送しなければなりません。 他のフレーム型のフレームや他のストリームのフレームを挟んではなりません。 >>73, >>24, >>26, >>29

[83] 未知のフレーム型のフレームも挟めません >>82。

[22] 多重化もできないなら、なぜ複数のフレームに分割できるようになっているのかは謎です。

[19] ヘッダーリストは、 HPACK によって圧縮します。 その符号化と復号に使う動的表は、接続単位で符号化用、 復号用に1つずつ存在します >>73。

HPACK を参照。[20] 同じ HTTP接続を使うHTTPメッセージは、要求と応答の組以外は互いに意味的に無関係です。 しかしそれを表現するフレーム列は、動的表を介して依存関係にあります。

符号化

[75] ヘッダーリストは、 HTTPヘッダー圧縮によりヘッダーブロックheader blockとして直列化されます >>73。

[76] 直列化されたヘッダーブロックは、1つ以上のヘッダーブロック素片header block fragmentに分割されて HEADERS, PUSH_PROMISE, CONTINUATION のフレームの payload (のヘッダーブロック素片Header Block Fragment欄 >>24, >>26, >>29) で転送されます >>73。

[11] どのように分割するかは、送信者に委ねられています。

[23] 意味的には分割してもしなくても同じです >>73。

復号

[18] CONTINUATION フレームではなく未知のフレーム型のフレームが現れた場合、接続エラー PROTOCOL_ERROR としなければなりません >>82。

[79] ヘッダーブロックの復号エラーは、接続エラー COMPRESSION_ERROR としなければなりません >>73。

[81] 受信者は、フレーム群が捨てられる場合であっても、 そのフレーム群からヘッダーブロックを結合し展開する必要があります。 受信者が持つ圧縮文脈を変更する可能性があります。 >>73, >>104, >>27 展開しない場合は、接続エラー COMPRESSION_ERROR としなければなりません >>73。

[28] closed 状態などでフレームを受信して無視する場合で接続エラーにはならない場合 (ストリームの項を参照。) や、GOAWAY フレーム送信後に受信して無視する場合、 ヘッダーブロックが長すぎて無視する場合があります。

[21] ヘッダー名やヘッダー値も、エラーを含む場合があります。

それぞれの項を参照。

サイズ制限

[86] 設定 SETTINGS_MAX_HEADER_LIST_SIZE (0x6) は、 送信者が受け付ける準備のできている header list の最大長を知らせるヒントです。 この値は、圧縮前の状態で、header field ごとに名前と値の長さとオーバーヘッドとして 32 を足した合計値をバイト単位にしたものです。 >>84

[89] 各要求で、この値よりも小さな制限を課しても構いません >>84。

[88] 初期値は、無制限です >>84。

[105] header block が大きいと、大量のデータを保持する必要が生じ、 不都合が生じるかもしれません。 header block の大きさに厳密な上限は設けていませんが、 設定 SETTINGS_MAX_HEADER_LIST_SIZE によって header block の大きさの制限を peer にヒントとして伝えられます。 peer はそれより大きな header block を送っても構いませんが、 奇形とみなされるリスクが有ります。 >>104

[106] 設定 SETTINGS_MAX_HEADER_LIST_SIZE は接続に対するもので、中間器を介した別のホップはより厳しい制限を持つかもしれません。 中間器は設定を転送することで問題を避けられますが、 そうする義務はありません。 >>104

[107] サーバーは、 header block が大きすぎて処理したくないときは 431 応答を送ることができます。 >>104

[108] クライアントは、 header block が大きすぎて処理したくないときは、 捨てることができます。 >>104

[109] 捨てるとしても、ヘッダー圧縮の展開処理は実行するか、 接続エラーとして接続を破棄しないといけません (>>81)。

[38] Chrome は 215 以下ならエラーとしないようです。 超えると接続エラー COMPRESSION_ERROR とするようです。 Firefox はそれよりずっと大きくてもエラーとしないようです。

処理

[32] HTTP/1.x でも HTTP/2 でも、エンドポイントは受信中のヘッダー部の全体を読み込んで処理を続けるか、 ヘッダー部を含むメッセージ全体 (とストリームや接続) をエラーとみなして処理を中断するかのいずれかとする必要があります。

[33] Content-Length: ヘッダーや疑似ヘッダーなど、 メッセージ全体の解釈に関わったり、場合によってエラーや奇形としなければならなかったりするヘッダーが含まれている可能性がありますから、 ヘッダー部全体を読み終わるまで、エンドポイントはアプリケーション側の処理を実行させることができません。 エンドポイントの HTTP 実装は (エラーとして処理を中断するのでなければ) すべてのヘッダーを読み終わるまで、必要なヘッダーを保持し続ける必要があります。

[34] 個々のヘッダーの処理については、HTTPヘッダーを参照。

関連

[46] HTTPメッセージは RFC 822メッセージから派生したものであり、 ヘッダー部も似たような構造を持っています。 ヘッダー部 (インターネットメール) も参照。

歴史

[45] ヘッダー部 (インターネットメール) も参照。

[1] Add sketch for headers · 50b8147 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/50b8147869f3d8d9fc2e29e09445176ac07391a6

[2] Define Headers object · 37526e4 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/37526e41d1da81e8b19a9d089ff16727eeda9dc8

[36] Issue 244260 - chromium - Security: TLS Truncation attack on HTTP headers, including cookie flags - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=244260

[40] Editorial: remove structured cloning section (annevk著, ) https://github.com/whatwg/fetch/commit/3dc1612fce7ab38673854d0bf26a4e118e52f077

[41] Simplify HeadersInit (annevk著, ) https://github.com/whatwg/fetch/commit/00fce0d96e799f5bc8bc53b30fcec56c4e0b948c

[42] Use IDL records for the Headers class (TimothyGu著, ) https://github.com/whatwg/fetch/commit/579e3637d0d82097baa1ee99b9d29e5f11aaa228

[156] 1197847 – dont allow line folding in h2 headers ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1197847

[158] Fix #154: clarify what a header list is · whatwg/fetch@3d7382b ( 版) https://github.com/whatwg/fetch/commit/3d7382b14b01f813e4023b4404422d377232e0c4

[43] Stop lowercasing header names (annevk著, ) https://github.com/whatwg/fetch/commit/5869c43a27fff06c6dfc228fe1288018f7f2168d

[44] RFC 7975 - Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection () https://tools.ietf.org/html/rfc7975#section-4.5

[48] Deprecations and Removals in Chrome 60  |  Web  |  Google Developers () https://developers.google.com/web/updates/2017/06/chrome-60-deprecations

[49] Constructing a Headers from another Headers is lossy · Issue #481 · whatwg/fetch () https://github.com/whatwg/fetch/issues/481

[50] Constructing a Headers from another Headers is lossy · Issue #481 · whatwg/fetch () https://github.com/whatwg/fetch/issues/481

[51] Define Content-Type manipulation in terms of MIME Sniffing by annevk · Pull Request #176 · whatwg/xhr () https://github.com/whatwg/xhr/pull/176

[52] Editorial: use Infra to define header list (annevk著, ) https://github.com/whatwg/fetch/commit/13504696e01852b3fc1bef242d8f3b649a397adb

[53] Use Infra for header list · Issue #711 · whatwg/fetch () https://github.com/whatwg/fetch/issues/711

[54] Editorial: use Infra to define header list by annevk · Pull Request #713 · whatwg/fetch () https://github.com/whatwg/fetch/pull/713

[55] Clarify how Headers does not support Set-Cookie (annevk著, ) https://github.com/whatwg/fetch/commit/7ab665e05e894f81d8ca741f7e7c19a334d88c08

[56] The comma-delimited combined value definition does not support Set-Cookie headers · Issue #345 · whatwg/fetch () https://github.com/whatwg/fetch/issues/345

[57] Clarify how Headers does not support Set-Cookie by annevk · Pull Request #714 · whatwg/fetch () https://github.com/whatwg/fetch/pull/714

[58] Editorial: use "append" to modify the header list (ryzokuken著, ) https://github.com/whatwg/fetch/commit/daca6a824c0c6c5e22b7f7eb70001f36c1732cb1

[59] Stop using "combined value" (annevk著, ) https://github.com/whatwg/xhr/commit/0d4253c784d2b71ca5bf6648c67f95b82bb8b239

[60] Remove "combined value" concept (yutakahirano著, ) https://github.com/whatwg/fetch/commit/8324d0a8192ce4b48de512d714726fe06fb92851

[61] Fix appending to Headers with "request-no-cors" guard (yutakahirano著, ) https://github.com/whatwg/fetch/commit/80d26b6d7a9089dbd18bb7de2ed2a60849824b02

[62] Fix: Appending a header to headers with "request-no-cors" guard by yutakahirano · Pull Request #840 · whatwg/fetch () https://github.com/whatwg/fetch/pull/840

[63] CORS request-header Content-Type check should be on a combined value · Issue #748 · whatwg/fetch () https://github.com/whatwg/fetch/issues/748

[64] Align with IDL constructor changes (autokagami著, ) https://github.com/whatwg/fetch/commit/eff7659a2cb15aed801a9dbfc00c58e22efbbd42