ヘッダー部 (HTTP)

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

仕様書

[6] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (2014-06-07 01:59:35 +09:00 版) https://tools.ietf.org/html/rfc7230#section-3
[73] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-4.3
[82] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-5.5
[24] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-6.2
[84] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-6.5.2
[26] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-6.6
[27] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-6.8
[29] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-6.10
[92] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-8.1.2
[104] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-10.5
[4] RFC 7541 - HPACK: Header Compression for HTTP/2 (2015-05-15 10:13:02 +09:00 版) https://tools.ietf.org/html/rfc7541#section-1.3
[3] Fetch Standard (2015-05-07 18:42:14 +09:00 版) https://fetch.spec.whatwg.org/#concept-header-list

ヘッダー部

[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 までが 2¹⁸-1 バイト (= 256KB-1B) 以下に収まっていなければならないようです。そうでなければ非文書表示でエラーとなります。 IE や Firefox は数MBより大きくても大丈夫なようです。制限があるのかは不明です。 2015-06-17T08:36:58.500Z

[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. 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 は 2¹⁵ 以下ならエラーとしないようです。超えると接続エラー COMPRESSION_ERROR とするようです。 Firefox はそれよりずっと大きくてもエラーとしないようです。 2015-10-11T08:12:14.200Z

処理

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

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