Tomcat gzip while chunked 问题

Question

我的一项数据源服务遇到了一些问题。正如 HTTP 响应标头中所述，它在 Apache-Coyote/1.1 上运行。服务器给出带有传输编码的响应：分块，这里是示例响应：

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Date: Tue, 30 Mar 2010 06:13:52 GMT

问题是当我请求服务器发送压缩请求时，它经常发送不完整的响应。我收到响应，看到收到的最后一个块，但在解压缩后，我看到响应是部分的。我从未见过在请求标头中关闭 gzip 时出现这种行为。

所以我的问题是：这是常见的tomcat问题吗？也许它的mod之一正在做压缩？或者也许是某种代理问题？我不知道 tomcat 的版本或他们使用的 gzip mod，但请随意询问，我会尝试询问我的服务提供商。

谢谢。

Answer 1

由于 gzip 压缩响应的内容长度是不可预测的，并且首先将其完全压缩到内存中，然后计算长度，然后从内存中流式传输 gzip 响应，这可能是昂贵且缓慢的，因此平均网络服务器将使用以下方式将它们分块发送： Transfer-Encoding: chunked 没有 A Content-Length 标头。

由于它是一个自行开发的 HTTP 客户端，因此听起来好像它无法正确处理分块请求。你必须确定 Transfer-Encoding 响应头，如果它等于 chunked, ，那么你必须将其解析为分块流。

您可以从上述 HTTP 规范链接和 维基百科 如何解析分块流。每个块由一个标头组成，该标头以十六进制表示块长度，然后是 CRLF，然后是实际块内容，然后是 CRLF。重复此操作，直到出现一个块，其标头表示块长度为 0. 。您需要分别解压这些块，然后将它们粘合在一起。

为了节省所有繁琐的编码工作（也可能是您自己开发的 HTTP 客户端的剩余部分），我强烈建议您查看 Apache HttpComponents 客户端.