ヘッダーブロック素片

ヘッダー部 (HTTP)

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

仕様書

ヘッダー部

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

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

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

ヘッダーリスト

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

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

HTTP/1.x ヘッダー部

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

[30] Chromeヘッダー部の末尾の CRLF までが 218-1 バイト (= 256KB-1B) 以下に収まっていなければならないようです。そうでなければ非文書表示でエラーとなります。 IEFirefox は数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

構文

[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. HEADERSEND_HEADERS)
        2. PUSH_PROMISEEND_HEADERS)
      2. *
        1. CONTINUATIONEND_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