トレーラー部 (HTTP)

[9] トレーラー部 (trailer part) は、chunked 符号化されているメッセージ本体の末尾のヘッダーを記述できる箇所です。

[10] トレーラー部を使うと、メッセージ本体の送信時に動的に生成される一貫性のデータやデジタル署名などをメッセージの末尾に記述することができます >>8。

[51] 実際には使われていません。

仕様書

[8] 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-4.1.2>
[26] 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-4.3>
[28] 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-4.4>
[36] RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (2014-08-07 05:54:02 +09:00 版) <https://tools.ietf.org/html/rfc7231#page-79>
[41] 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.2>
[43] 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.1>

構文

[11] トレーラー部は、0個以上のヘッダーで構成されます。各ヘッダーの後には、 CRLF が来ます。 >>8

*
1. ヘッダー
2. CRLF

[40] HTTP/2 では、 HEADERS フレームや CONTINUATION フレームによる header block として表されます。

HTTPメッセージ参照。

文脈

[23] トレーラー部は、 HTTP/1.1 chunked 符号化されている場合にメッセージ本体の末尾近くに、または HTTP/2 メッセージを表すフレームの末尾に存在しています。

chunked、ヘッダー部、HTTPメッセージも参照。

[25] 利用者エージェントは要求の TE: ヘッダーに trailers >>26 という値を指定することで、トレーラー部に対応していると明示できます。

[27] 中間器が送信する場合、下流すべてがトレーラー部に対応しているか、中間器がバッファリングしてから下流に渡すかのいずれかを表します >>26。

[42] HTTP/2 は TE: ヘッダーの値として trailers のみを認めています >>41。

[21] サーバーは、 TE: に trailers が指定されている場合を除き、利用者エージェントに必要と考えられるヘッダーをトレーラー部で生成するべきではありません。鯖は、 TE: に trailers が指定されていない場合には、トレーラー部のヘッダーは利用者エージェントへの経路中で黙って捨てられるかもしれないと考えるべき (ought to) です。 >>8

[22] 中間器は chunked 符号化を復号して HTTP/1.0 受信者に転送するかもしれませんが、その際に応答全体をバッファリングする必要はありません >>8。

[24] TE: trailers が指定されていなくても、トレーラー部の利用が禁止されているわけではないようです。しかし指定されていない場合には、トレーラー部が理解される保証は全くありません。

ヘッダーの種類

[12] 送信者は、次のようなヘッダーを生成してはなりません。受信者は、これらを無視するか、誤りとみなすかしなければなりません。 >>8

[13] メッセージのフレーム付けに関するもの (Transfer-Encoding:、 Content-Length: など)
[14] 経路制御に関するもの (Host: など)
[15] 要求修飾子
[16] 認証
[17] 応答制御データ
[18] payload の処理方法に関するもの (Content-Encoding:、 Content-Type:、Content-Range:、 Trailer: など)

[19] なぜか完全なリストはなく、例示に留まっています。

[44] 疑似ヘッダーを含んではなりません。含んでいる場合、メッセージは奇形です。 >>43

[37] RFC 7231 はヘッダーの仕様書に対し、トレーラー部で使用することを認めるかどうか、便利かどうかを明記することを検討するよう求めています >>36。

[20] 禁止されているものを除いたヘッダーは、頭部に現れた場合と同じように処理して構いません。 >>8

[38] 次のヘッダーはトレーラー部での使用が明示的に認められています。

[35] トレーラー部で使って良いもの、使っていけないものに該当すると思われるヘッダーの一覧は >>6 に JSON 形式で収録されています。

[6] data-web-defs/headers.txt at master · manakai/data-web-defs (2014-09-03 10:02:34 +09:00 版) <https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt>

[39] トレーラー部のヘッダーは、使用が認められていないものは無視されますし、それ以外であっても無視される可能性があります。また通常のヘッダー部とトレーラー部の両方に同名のヘッダーが含まれていると、どちらを採用するかが実装により異なる可能性もあります。これは相互運用性の問題を生じるだけでなく、セキュリティー上の問題となる危険性もあります。

処理

[45] トレーラー部のヘッダーのエラー処理をどうするべきなのか、あまり明確ではありません。

[46] ヘッダーの受信完了後、payload body やトレーラー部の全体を受信せずとも処理を開始できます。その後にトレーラー部を受信した結果エラーが検出された場合、既に開始されている処理は止められないかもしれません。

[50] 現在のどの Webブラウザーも、トレーラー部が含まれていたら正しく扱えますが、その内容は無視するようです。 2015-08-08T07:08:53.300Z

`Trailer:` ヘッダー (HTTP)

[2] Trailer: ヘッダーは、トレーラー部に含まれるヘッダー名を表しています。

文脈

[30] このヘッダーは複数指定できます。

[31] 送信者はトレーラー部でヘッダーを送りたいときは、頭部に Trailer: ヘッダーを生成して当該ヘッダー名を含めるべきです >>28。

構文

[29] ヘッダー名の1つ以上のリスト (#) です >>28。

ヘッダー名
*
1. FWS
2. ,
3. FWS
4. ヘッダー名

処理

[32] 受信者に対するヒントとして用いることが想定されているようで、具体的にどのように処理するかは規定がありません。また、トレーラー部を使用する時に指定することが推奨はされていますが、実態と一致していない可能性は排除されていませんし、その場合のエラー処理も特に規定されていません。

[59] プロキシが転送前または転送後のプロトコルでトレーラー部を扱えない場合、削除するべきだと思われます。

歴史

[4] RFC 2616 (HTTP/1.1) 14.40 Trailer

The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.

Trailer (尻尾) 全般領域値は、指定された頭領域の集合が chunked (塊) 転送符号化で符号化されたメッセージの尻尾にあることを示します。

Trailer = "Trailer" ":" 1#field-name

An HTTP/1.1 message SHOULD include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer.

HTTP/1.1 メッセージは、空でない尻尾の塊転送符号化を使うメッセージには、 Trailer 頭領域を含めるべきです。そうすることで、受信者はどの頭領域が尻尾に巻かれて来ようかを知ることが出来ます。

If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a "chunked" transfer-coding.

Trailer 頭領域が無い場合、尻尾にはどんな頭領域も含めるべきではありません。「chunked」転送符号化で尻尾領域を使う際の制限については、 3.6.1節を参照して下さい。