我的一个数据源服务遇到问题。就像它在HTTP响应标头中所说的那样,它运行在Apache-Coyote / 1.1上。服务器使用Transfer- Encoding进行响应:分块,此处为示例响应:
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问题吗?也许其中之一是进行压缩的国防部?也许是某种代理问题?我不能说出tomcat的版本或它们使用的gzip mod,但是请随时询问,我将尝试询问我的服务提供商。
谢谢。
由于一个压缩响应的内容长度是不可预测的和它的潜在昂贵而缓慢到存储器中第一个完全压缩,然后计算出的长度,然后流从存储器用Gzip响应,平均web服务器将在使用组块发送它们 没有 一个标头。Transfer- Encoding: chunked __Content-Length
Transfer- Encoding:
chunked
Content-Length
由于它是本地HTTP客户端,因此听起来好像没有正确处理分块的请求。您必须确定Transfer- Encoding响应标头,如果它等于chunked,则必须将其解析为分块流。
Transfer- Encoding
您可以从上述HTTP规范链接和Wikipedia中学习如何解析分块的流。每个块均由标头(以十六进制表示)的长度组成,然后是CRLF,然后是实际块内容,然后是CRLF。重复此过程,直到带有标题的块表示标题的块长度0。您需要分别解压缩块,然后将它们粘合在一起。
0
为了节省所有繁琐的编码工作(可能还用于您自己的HTTP客户端的剩余部分),我强烈建议您看看Apache HttpComponents Client。