问是否有浏览器支持以分块编码响应发送的预告片？

EN

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。

现在，从我所读到的所有东西来看，拖车很少被使用(如果有的话)。大多数关于拖车的这里和其他方面的讨论通常以“但你为什么要使用拖车？”开始。

出于好奇，我一直在尝试模拟使用预告片的HTTP请求/响应交换(HTTP request/response exchange )，但到目前为止，我还无法让它工作，我也不确定我正在生成的响应是否有问题，或者(正如一些人所建议的那样)是否根本没有客户端寻找尾随的标题。

我试过的客户包括: curl，wfetch，Chrome + jQuery。

在所有情况下，客户端接收并正确地重新构造块响应(All your base are belong to us)；我可以在响应头中看到Trailer: My-Test-Trailer正在发送的响应头；但我没有看到在响应头或任何地方返回的My-Test-Trailier: something。在接收到整个响应并关闭连接之后，这样的尾随头是否应该作为正常的响应头出现在客户机中还不清楚？

有趣的是，卷曲变化日志似乎表明curl确实支持可选的拖车，而curl将处理它找到的任何进入正常的标头流拖车。

有没有人知道：

• 我可以点击一个有效的URL，它会在一个分块的响应中发送拖车？(这样我就可以确认是否只是我的测试响应不起作用了)；
• 已知哪些客户端支持(以及访问/显示)服务器发送的拖车？