我正在为透明代理编写HTTP解析器。令我感到困惑的是Trailer:
规范中提到的Transfer-Encoding: chunked
。它看起来像什么?
通常情况下,HTTP chunked就是这样结束的。
0\r\n
\r\n
我感到困惑的是,如果有某种尾随标题,如何检测块的结尾......
更新:我认为简单的\r\n\r\n
即空行足以检测尾随标题的结尾......这是正确的吗?< / p>
答案 0 :(得分:16)
以下是我从The TCP/IP Guide site复制的示例预告片的副本。
正如我们所看到的,如果我们想要使用预告片头,我们需要添加一个&#34;预告片:header_name&#34;带有标题名称的标题字段,然后在分块的正文区域后添加预告片标题实体。
我们可以根据RFC在HTTP正文中添加0个或更多个预告片头。 RFC7230的第4.1.2节禁止在预告片标题区域中使用以下标题:
发件人不得生成包含必填字段的预告片 对于消息成帧(例如,传输编码和内容长度), 路由(例如,主机),请求修改器(例如,控制和 RFC7231)第5节中的条件,验证(例如,见 RFC7235和RFC6265),响应控制数据(例如,请参阅第7.1节 of RFC7231),或确定如何处理有效载荷(例如, 内容编码,内容类型,内容范围和预告片。
这意味着我们可以在预告片标题区域中使用其他标准标头和自定义标头。
答案 1 :(得分:15)
0 \ r \ n
SomeAfterHeader:TheData \ r \ n
的 \ r \ n 强>
换句话说,用外行的术语来寻找 \r\n\r\n
就足够了:一个空行。检测分块传输的结束。但是在执行此操作之前读取每个块非常重要。因为分块数据本身可以包含空行,这些行将被错误地检测为流的末尾。
答案 2 :(得分:13)
关于预告片:
如您所知,应在“预告片”标题中指定尾随标题列表。
Section 14.40 of RFC 2616中的BNF是这样的:
Trailer = "Trailer" ":" 1#field-name
Gourley和Totty举了这个例子:
Trailer: Content-Length
(奇怪的是他们给出了这个例子,因为在14.40中明确禁止Content-Length成为尾随标题。)
Shiflett举了这个例子:
Trailer: Date
关于带尾随标题的邮件结尾:
Section 3.6.1 of RFC 2616中的BNF正是您所寻找的。这是部分:
Chunked-Body = *chunk
last-chunk
trailer
CRLF
last-chunk = 1*("0") [ chunk-extension ] CRLF
trailer = *(entity-header CRLF)
所以最后一个chunk和2个尾随标题可能如下所示:
0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>