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
),然后是 final 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,它在分块响应中发送预告片?(以便我可以确认是否只是我的测试响应不起作用);和
- 已知哪些客户端支持(和访问/显示)服务器发送的预告片?