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标题中指定了它将发送的预告片列表（在这种情况下，只有一个：My-Test-Trailer）
每个块都以：
发送D = 13），后跟CRLF All your base），后跟CRLF 零大小的块（0\r\n）表示正文的结尾。
然后指定预告片（My-Test-Trailer: something\r\n），然后是最终CRLF。
现在，从我到目前为止所阅读的所有内容来看，预告片很少（如果曾经使用过）。关于预告片的大多数讨论here和其他地方通常以“但你为什么还想使用预告片？”开始。
暂且不谈为什么，出于好奇，我一直试图模拟使用预告片的HTTP请求/响应交换;但到目前为止，我还没有能够让它工作，我不确定我生成的响应是否有问题，或者是否（正如一些人所建议的那样）没有客户端寻找尾随的标题
我尝试过的客户包括：curl，wfetch，Chrome + jQuery。
在所有情况下，客户端都会接收并正确重建分块响应（All your base are belong to us）;我可以在响应标题中看到Trailer: My-Test-Trailer正在发送;但我没有看到My-Test-Trailier: something在响应标头或任何地方返回。
在收到整个响应并关闭连接之后，不清楚这样的尾随标题是否应作为正常响应标题出现在客户端中？
有趣的是，curl change logs似乎表明curl 支持支持可选预告片，而卷曲会处理它找到的所有预告片into the normal header stream。
所有人都知道：
答案 0 :(得分：6)
自问这个问题以来已有5年多了，我现在可以自己明确回答。
Mozilla刚宣布他们将支持新的Server-Timing字段作为HTTP尾随标头（他们首次支持预告片）。
https://bugzilla.mozilla.org/show_bug.cgi?id=1413999
然而，更重要的是，他们确认会将其列入白名单，以便Server-Timing是唯一支持价值（强调我的）：
Server-Timing是一个HTTP预告片，而不是标头。 ：mcmanus告诉我我们目前正在解析预告片，但是然后默默地将它们扔掉。我们一般不想改变这种行为（我们不想鼓励预告片），所以我们要将服务器定时预告片列入白名单，将其存储在某处（可能只是mServerTiming标头将现在工作，因为它是我们支持的唯一预告片，然后通过一些新的channel.getTrailers（）调用使其可用。
所以我想这一劳永逸地证实了这一点：Moz不支持尾随标题（并且通常不会在一般意义上），并且可能所有其他浏览器供应商采取相同的立场。
答案 1 :(得分：3)
自this commit以来，Jodd HTTP Java client支持预告片标题。
关于第一个问题，我还没有找到任何使用它们的实时回复;）
答案 2 :(得分：0)
就在最近，据 caniuse.com 称，大多数主要浏览器提供商现在都在其最新版本中支持 Trailer 响应标头（例如 Firefox-88、Safari-14.1、Chrome-88、等）。
然而，这似乎只是由于他们对 Server-Timing 的支持（可以使用另一个答案中提到的预告片），目前似乎没有一种通用的方法可以从浏览器 Javascript - 目前是 open issue for the Fetch API，以及 trailers in Chrome is marked wontfix 的错误请求。