6

我的一项数据源服务遇到了一些问题。正如它在 HTTP 响应标头中所说，它在 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

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

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

谢谢。

4

1 回答 1

3

由于 gzip 响应的内容长度是不可预测的，并且首先在内存中完全压缩它可能很昂贵且速度很慢，然后计算长度，然后从内存中流式传输 gzip 响应，因此平均网络服务器将使用不带标题的块发送它们。Transfer-Encoding: chunked Content-Length

由于它是一个自制的 HTTP 客户端，因此听起来好像它不能正确处理分块请求。您必须确定Transfer-Encoding响应标头，如果它等于chunked，则必须将其解析为分块流。

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

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

于 2010-04-07T22:11:23.167 回答