Tomcat gzip while chunked 问题
我的一项数据源服务遇到了一些问题。 正如 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
问题是当我请求服务器发送 gzipped 请求时，它经常发送不完整的响应。我收到响应，看到收到的最后一个块，但在解压缩后，我看到响应是部分的。我从未见过在请求标头中关闭 gzip 时出现这种行为。
所以我的问题是：这是常见的 tomcat 问题吗？也许它的mod之一正在做压缩？或者也许是某种代理问题？我不知道 tomcat 的版本或他们使用的 gzip mod，但请随意询问，我会尝试询问我的服务提供商。
谢谢。
I'm expiriencing some problem with one of my data source services.
As it says in HTTP response headers it's running on Apache-Coyote/1.1.
Server gives responses with Transfer-Encoding: chunked, here sample response:
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
And problem is when I'm requesting server to send gzipped request it often sends not full response. I recieve response, see that last chunk recieved, but then after ungzipping I see that response is partial. I never seen such behavior with gzip turned off in request headers.
So my question is: is it common tomcat issue? maybe one of it's mod which is doing compression? Or maybe it maybe some kind of proxy issue? I can't tell about versions of tomcat or what gzip mod they use, but feel free to ask, i'll try ask my service provider.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于 gzip 压缩响应的内容长度是不可预测的，并且首先将其完全压缩到内存中，然后计算长度，然后从内存中流式传输 gzip 响应，因此可能会昂贵且缓慢，因此一般 Web 服务器将使用
传输编码：分块没有< /em>Content-Length标头。由于它是一个自行开发的 HTTP 客户端，因此听起来好像它无法正确处理分块请求。您必须确定 Transfer-Encoding 响应标头，如果它等于分块，则必须将其解析为分块流。
您可以从上述 HTTP 规范链接和 Wikipedia 了解如何解析分块流。每个块由一个标头组成，该标头以十六进制表示块长度，然后是 CRLF，然后是实际块内容，然后是 CRLF。重复此操作，直到出现一个块，其标头表示块长度为
0。您需要分别解压这些块，然后将它们粘合在一起。为了节省所有繁琐的编码工作（也可能是您自己开发的 HTTP 客户端的剩余部分），我强烈建议您查看 Apache HttpComponents 客户端。
Since the content length of a gzipped response is unpredictable and it's potentially expensive and slow to compress it fully in memory first, then calculate the length and then stream the gzipped response from memory, the average webserver will send them in chunks using
Transfer-Encoding:chunkedwithout aContent-Lengthheader.Since it's a homegrown HTTP client, it sounds like as if it doesn't handle chunked requests correctly. You have to determine the
Transfer-Encodingresponse header and if it equals tochunked, then you have to parse it as a chunked stream.You can learn from the aforementioned HTTP spec links and from Wikipedia how to parse a chunked stream. Each chunk consists of a header denoting the chunk length in hexadecimal, then a CRLF, then the actual chunk content, then a CRLF. This is repeated until a chunk with a header denoting the chunk length of
0. You need to ungzip the chunks separately and then glue them together.To save all the tedious coding work (likely also for the remnant of your homegrown HTTP client), I strongly recommend to have a look at Apache HttpComponents Client.