分块问题时 Tomcat gzip

Question

我的一项数据源服务遇到了一些问题。 正如它在 HTTP 响应 header 中所说，它在 Apache-Coyote/1.1 上运行。 服务器使用 Transfer-Encoding: chunked 给出响应，这里是示例响应:

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

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

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

谢谢。

Answer 1

由于 gzip 响应的内容长度是不可预测的，并且首先在内存中完全压缩它可能很昂贵且速度慢，然后计算长度，然后从内存中流式传输 gzip 响应，一般的网络服务器将使用 Transfer-Encoding: 以 block 的形式发送它们chunked 没有 Content-Length header 。

因为它是一个本地开发的 HTTP 客户端，所以听起来好像它不能正确处理分块请求。您必须确定 Transfer-Encoding 响应 header ，如果它等于 chunked，那么您必须将其解析为分块流。

您可以从上述 HTTP 规范链接和 Wikipedia 中了解如何解析分块流。每个 block 包含一个以十六进制表示 block 长度的 header ，然后是 CRLF，然后是实际的 block 内容，然后是 CRLF。重复此操作，直到一个 header 表示 0 的 block 长度的 block 。您需要分别解压缩这些 block ，然后将它们粘合在一起。

为了节省所有繁琐的编码工作(也可能用于您自己开发的 HTTP 客户端的剩余部分)，我强烈建议您查看 Apache HttpComponents Client。