HTTP 分块编码。需要一个“预告片”的例子; SPEC中提到

发布于 2024-10-30 19:56:08 字数 313 浏览 1 评论 0原文

我正在为透明代理编写一个 HTTP 解析器。让我感到困惑的是 Transfer-Encoding: chunked 规范中提到的 Trailer:。它看起来像什么?

通常,HTTP 分块是这样结束的。

0\r\n
\r\n

我感到困惑的是,如果存在某种尾随标头,如何检测块的结尾...

更新: 我相信一个简单的 \r\n\r\n空行足以检测尾随标头的末尾...这是正确的吗?

I am writing an HTTP parser for a transparent proxy. What is stumping me is the Trailer: mentioned in the specs for Transfer-Encoding: chunked. What does it look like?

Normally, a HTTP chunked ends like this.

0\r\n
\r\n

What I am confused about is how to detect the end of the chunk if there is some sort of trailing headers...

UPDATE: I believe that a simple \r\n\r\n i.e. an empty line is enough to detect the end of trailing headers... Is that correct?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

只等公子 2024-11-06 19:56:08

0\r\n
SomeAfterHeader:TheData \r\n
\r\n

换句话说,寻找一个\r\n\r\n就足够了,通俗地说:< em>一个空行。检测分块传输的结束。但在执行此操作之前读取每个块非常重要。因为分块数据本身可能包含空白行,这些空白行会被错误地检测为流的末尾。

0\r\n
SomeAfterHeader: TheData \r\n
\r\n

In other words, it is sufficient to look for a \r\n\r\n, in layman's terms: a blank line. To detect the end of a chunked transmission. But it is very important that each chunk is read before doing this. Because the chunked data itself can contain blank lines which would erroneously be detected as the end of the stream.

妄司 2024-11-06 19:56:08

下面是我从 TCP/IP 指南站点
trailer example

正如我们所看到的,如果我们想使用预告片标头,我们需要添加一个“Trailer:header_name”标头字段带有标头名称,然后在分块主体区域之后添加预告片标头实体。

我们可以根据 RFC 在 HTTP 正文中添加 0 个或多个尾部标头。
RFC7230 的第 4.1.2 节禁止使用以下标头在拖车标题区域:

发送者不得生成包含必要字段的预告片
对于消息帧(例如,传输编码和内容长度),
路由(例如,主机)、请求修饰符(例如,控件和
RFC7231 第 5 节中的条件句)、身份验证(例如,参见
RFC7235RFC6265),响应控制数据(例如,参见第 7.1 节
RFC7231),或确定如何处理有效负载(例如,
内容编码、内容类型、内容范围和预告片)。

这意味着我们可以在预告片标头区域中使用其他标准标头和自定义标头。

Below is a copy of an example trailer I copied from The TCP/IP Guide site.
trailer sample

As we can see, if we want to use trailer header, we need add a "Trailer:header_name" header field with a header name and then add the trailer header entity after chunked body area.

We can add 0 or more trailer headers in a HTTP body per the RFC.
Section 4.1.2 of RFC7230 bans the use of following headers in trailer header area:

A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of RFC7231), authentication (e.g., see
RFC7235 and RFC6265), response control data (e.g., see Section 7.1
of RFC7231), or determining how to process the payload (e.g.,
Content-Encoding, Content-Type, Content-Range, and Trailer).

This means we can use other standard headers and custom headers in trailer header area.

她比我温柔 2024-11-06 19:56:08

关于预告片:

正如您所注意到的,尾随标头列表应在预告片标头中指定。

RFC 2616 第 14.40 节 中的 BNF 是这样的:

Trailer  = "Trailer" ":" 1#field-name

Gourley 和 Totty给出这个例子:(

Trailer: Content-Length

他们给出这个例子很奇怪,因为 Content-Length 在 14.40 中被明确禁止作为尾随标头。)

Shiflett 给出了这个例子:

Trailer: Date

头的消息结束:

关于带有尾随标 RFC 2616 第 3.6.1 节 中的 BNF 是您的内容正在寻找。这是部分:

Chunked-Body = *chunk
               last-chunk
               trailer
               CRLF
last-chunk   = 1*("0") [ chunk-extension ] CRLF
trailer      = *(entity-header CRLF)

所以最后一个块和 2 个尾随标头可能如下所示:

0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>

Regarding trailer:

The list of trailing headers should be specified in the Trailer header, as you note.

The BNF in Section 14.40 of RFC 2616 is this:

Trailer  = "Trailer" ":" 1#field-name

Gourley and Totty give this example:

Trailer: Content-Length

(It's odd that they give this example, since Content-Length is explicitly forbidden to be a trailing header in 14.40.)

Shiflett gives this example:

Trailer: Date

Regarding end of message with trailing headers:

The BNF in Section 3.6.1 of RFC 2616 is what you're looking for. Here's part:

Chunked-Body = *chunk
               last-chunk
               trailer
               CRLF
last-chunk   = 1*("0") [ chunk-extension ] CRLF
trailer      = *(entity-header CRLF)

So the last chunk and 2 trailing headers might look like this:

0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文