压缩编码响应的gzip压缩?

时间:2011-03-12 04:49:58

标签: http gzip chunked-encoding

我正在尝试让我的网络服务器正确地gzip一个块响应的http响应。

我对非gzip响应的理解是它看起来像这样:

<the response headers>

然后为每个块,

<chunk length in hex>\r\n<chunk>\r\n

最后,零长度块:

0\r\n\r\n

我试图让gzip压缩工作,我可以使用一些帮助找出实际应该返回的内容。这个文档暗示整个响应应该被gzip压缩,而不是gzipping每个块:

HTTP servers sometimes use compression (gzip) or deflate methods to optimize transmission.
Chunked transfer encoding can be used to delimit parts of the compressed object.
In this case the chunks are not individually compressed. Instead, the complete payload 
is compressed and the output of the compression process is chunk encoded.

我尝试gzip整个事情并返回响应,即使没有分块,它也没有用。我尝试将Content-Encoding标头设置为“gzip”。有人可以解释必须对上述方案进行哪些更改才能支持gzipping的大小调整?感谢。

3 个答案:

答案 0 :(得分:32)

如果其他答案不够清楚:

首先你用zlib gzip body(这可以在一个流中完成,所以你不需要在内存中同时存在整个内容,这就是分块的全部内容。)

然后使用Content-Encoding:gzip和Transfer-Encoding:chunked headers(并且没有)将块中的压缩体(可能是gzip流提供的块,以及块头来声明它的长度)发送Content-Length标题)。

如果您使用gzip或zcat或某些此类实用程序进行压缩,则可能无法正常工作。需要成为zlib。如果你正在创建块然后压缩它们,那肯定是行不通的。如果您认为自己正在做这件事并且无法正常工作,那么您可能会尝试进行数据包跟踪,并根据该问题以及您收到的任何错误消息提出问题。

答案 1 :(得分:22)

你gzip内容,然后才应用分块编码:

“由于”chunked“是HTTP / 1.1接收者需要理解的唯一传输编码,因此它在分隔持久连接上的消息方面起着至关重要的作用。每当传输编码应用于有效载荷主体时请求,应用的最终传输编码必须“分块”。如果传输编码应用于响应有效负载主体,则应用的最终传输编码必须“分块”或者必须通过关闭连接来终止消息当使用“分块”传输编码时,它必须是用于形成消息体的最后一个传输编码。“分块”传输编码绝不能在消息体中多次应用。“< / p>

HTTPbis Part1, Section 6.2.1

答案 2 :(得分:1)

可能你并没有真正发送适当的gzipped响应。

尝试在zlib中将window bits设置为31。并使用deflateInit2()