HTTP/1.1は、送信される応答Transfer-Encoding: chunkedにオプションのトレーラーを含めることができることを指定しています (つまり、通常はヘッダーとして送信されるものですが、何らかの理由でコンテンツの前に計算できないため、末尾に追加できます)。例:
リクエスト：
GET /trailers.html HTTP/1.1
TE: chunked, trailers
応答：
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: My-Test-Trailer
D\r\n
All your base\r\n
B\r\n;
are belong\r\n
6\r\n
to us\r\n
0\r\n
My-Test-Trailer: something\r\n
\r\n
このリクエストは、TEヘッダーで、レスポンスを期待していることを指定し、最後のチャンクの後chunkedに探します。trailers
応答は、Trailer送信するトレーラーのリストをヘッダーで指定します (この場合、1 つだけ: My-Test-Trailer)
各チャンクは次のように送信されます。
- チャンクのサイズ (16 進数 (
D= 13))、その後にCRLF - チャンク データ (
All your base)、その後にCRLF
サイズがゼロのチャンク ( 0\r\n) は、本文の終わりを示します。
次に、トレーラーが指定され ( My-Test-Trailer: something\r\n)、最後に が続きCRLFます。
さて、私がこれまでに読んだすべてのことから、予告編は (あったとしても) めったに使用されません。予告編に関するここや他の場所でのほとんどの議論は、通常、「しかし、なぜ予告編を使用したいのですか?」で始まります。
なぜという疑問はさておき、私は好奇心から、トレーラーを使用する HTTP 要求/応答交換をシミュレートしようとしました。しかし、これまでのところ私はまだそれを機能させることができておらず、私が生成している応答に何か問題があるのか 、それとも（一部の人が示唆しているように）末尾のヘッダーを探すクライアントが単にないのかどうかはわかりません. .
私が試したクライアントには、curl、wfetch、Chrome + jQuery などがあります。
いずれの場合も、クライアントはチャンク化された応答を受信し、正しく再構築します ( All your base are belong to us)。Trailer: My-Test-Trailer送信されている応答ヘッダーで確認できます。My-Test-Trailier: somethingしかし、応答ヘッダーまたはどこにも返されていません。応答全体が受信され、接続が閉じられた後、このような末尾のヘッダーが通常の応答ヘッダーとしてクライアントに表示されるかどうかは不明ですか?
興味深いことに、curl の変更ログは、curlがオプションのトレーラーをサポートしていること、および curl が検出したトレーラーを通常のヘッダー ストリームに処理することを示唆しているように見えます。
誰も知っていますか：
- チャンクされた応答でトレーラーを送信する有効な URL を ping できますか? （それが機能していないのが私のテスト応答であるかどうかを確認できるようにするため）; と
- サーバーから送信されたトレーラーをサポート (およびアクセス/表示) することが知られているクライアントはどれですか?