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

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

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

仕様書

構文

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

  1. *
    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

[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 ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt

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

処理

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

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

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

Trailer: ヘッダー (HTTP)

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

文脈

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

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

構文

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

  1. ヘッダー名
  2. *
    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 (塊) 転送符号化で符号化されたメッセージの尻尾に あることを示します。

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節を参照して下さい。

Message header fields listed in the Trailer header field MUST NOT include the following header fields:

Trailer 頭欄に列せられるメッセージ頭欄には、 次に挙げる頭欄を含めてはいけません。

  • Transfer-Encoding
  • Content-Length
  • Trailer

Trailers: ヘッダー

[3] RFC 2616 は Trailer: ヘッダーのことを Trailers: としているところがあり、 正誤表で訂正されています。

  • [5] HTTP/1.1 Specification Errata http://purl.org/NET/http-errata#trailer-hop)

メモ

[1] Trailer: 欄に挙げてはみたけど、やっぱりや〜めた、ってのはありなのかな? どうなのかな?

[7] CGI や PHP のようなサーバー側の処理で応答を出力する時に、内容を送りつつ最後に確定した追加の欄を送る、という使い方が想定されているのでしょうが、実際のところ、この欄とその機能のちゃんとした実装があるのかすら不明です。 現状では実質使えない機能だと考えても良いでしょう。

更に、計算機や回線の性能はよくなってきていますから、 内容と欄を全て生成してから一気に送るというやり方でもほとんど問題がなくなってきています。 ですからこの欄もこのまま使われずに完全に忘れられるかもしれません。

[33] HTTP Chunking peculiarities ( (Martin Holst Swende 著, 版)) http://martin.swende.se/blog/HTTPChunked.html

[34] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.1

[47] GoでHTTP Trailerを扱う - Qiita ( 版) http://qiita.com/ono_matope/items/89ce7f491b791dece38c

[48] Issue 33325 - chromium - Support trailers for HTTP chunked transfer-coding - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=33325

[49] 698313 – Headers in chunked transfer encoding trailers are not size limited ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=698313

[52] Server Timing ( 版) https://w3c.github.io/server-timing/#processing-model

The user-agent must process Server-Timing header field communicated via a trailer field (see [RFC7230] section 4.1.2) using the same algorithm.

[53] Access to the HTTP trailer · Issue #34 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/issues/34

[54] Editorial: rename end-of-file to end-of-body (annevk著, ) https://github.com/whatwg/fetch/commit/483ffd8c4984b306a262f3b11711747023c0d395

[55] grpc/grpc: The C based gRPC (C++, Node.js, Python, Ruby, Objective-C, PHP, C#) () https://github.com/grpc/grpc

Status and Trailing-Metadata are sent as HTTP/2 trailing headers (a.k.a., trailers).

[56] Add trailer support to network responses (annevk著, ) https://github.com/whatwg/fetch/commit/427255ebd4b07c4912292dbb3a24f97bfa8d1c8a

[57] Response's trailer cannot use [SameObject] (annevk著, ) https://github.com/whatwg/fetch/commit/7c256a597fb895910d212caf253737c7f5e2c4ae

[58] 691599 - Add Fetch's Response's trailer attribute - chromium - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=691599

[60] Abortable fetch (jakearchibald著, ) https://github.com/whatwg/fetch/commit/0bcd5dfc71ef44319873887f4b83119bd6d0b71d

[61] Trailers · Issue #16 · httpwg/http-core () https://github.com/httpwg/http-core/issues/16