我在使用我的某个数据源服务时遇到了一些问题。 正如它在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压缩请求时，它经常发送不完整的响应。我收到回应，看到最后一块收到了，但是在解开后我看到回复是偏的。我从未在请求标头中关闭gzip这种行为。
所以我的问题是：它是常见的tomcat问题吗？也许其中一个mod正在进行压缩？或者也许它可能是某种代理问题？我不知道tomcat的版本或者他们使用的是什么gzip mod，但随便问一下，我会试着询问我的服务提供商。
感谢。
答案 0 :(得分：2)
由于gzip压缩的内容长度是不可预测的，并且它可能很昂贵而且在内存中完全压缩它的速度很慢，然后计算长度，然后从内存中流式传输gzip压缩，平均网络服务器将使用{ {3}} Transfer-Encoding: 没有 Content-Length标题。
由于它是一个自行开发的HTTP客户端，听起来好像它没有正确处理分块请求。您必须确定Transfer-Encoding响应标头，如果它等于chunked，则必须将其解析为分块流。
您可以从前面提到的HTTP规范链接和chunked中学习如何解析分块流。每个块包含一个标题，表示以十六进制表示的块长度，然后是CRLF，然后是实际的块内容，然后是CRLF。重复此过程直到具有表示块长度0的标题的块。您需要单独解压缩块，然后将它们粘合在一起。
要保存所有繁琐的编码工作（可能还有本地HTTP客户端的剩余部分），我强烈建议您查看Wikipedia。