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

Question

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),然后是aCRLF
• 块数据(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会将它找到的任何预告片处理到正常的标题流中.

所以有人知道:

• 我可以ping的有效URL,它在一个分块响应中发送预告片？(这样我才能确认这是否只是我的测试响应不起作用); 和
• 已知哪些客户端支持(和访问/显示)服务器发送的预告片？

Answer 1

没有常见的浏览器支持HTTP/1.1预告片.查看browserscope的"网络"选项卡中的"预告片中的标题"列.

• Chrome:不,不会修复(bug).支持H/2预告片(bug).
• Firefox:不,我没有在bugzilla中看到它的票.似乎支持H/2.
• IE:不
• 边缘:没有
• Safari:没有
• Opera:仅限旧版本(v10 - 12,14中删除)

正如您所发现的,许多非浏览器客户端都支持它.

Answer 2

提出这个问题已经超过5年了,我现在可以自己肯定地回答这个问题了.

Mozilla刚宣布他们将支持新Server-Timing领域作为HTTP尾随标题(他们首次支持预告片).

https://bugzilla.mozilla.org/show_bug.cgi?id=1413999

然而,更重要的是,他们确认它将被列入白名单,因此这Server-Timing是唯一的支持价值(强调我的):

Server-Timing是一个HTTP预告片,而不是标头.:mcmanus告诉我,我们目前解析预告片,但然后默默地扔掉它们.我们一般不想改变这种行为(我们不想鼓励预告片),所以我们要将Server-Timing预告片列入白名单,将其存储在某处(可能只是mServerTiming标头现在可以使用,因为它是我们支持的唯一预告片,然后通过一些新的channel.getTrailers()调用使其可用.

所以我想这一劳永逸地证实了这一点:Moz不支持尾随标题(并且从不可能是一般意义上的),并且可能所有其他浏览器供应商采取相同的立场.