Tomcat gzip出现分块问题时 [英] Tomcat gzip while chunked issue

问题描述

我的一个数据源服务遇到问题. 就像它在HTTP响应标头中所说的那样，它运行在Apache-Coyote/1.1上. 服务器使用Transfer-Encoding进行响应:分块，此处为示例响应:

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

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

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.

所以我的问题是:这是常见的tomcat问题吗?也许其中之一是进行压缩的mod?也许这可能是某种代理问题?我不能说出tomcat的版本或它们使用的gzip mod，但请随时询问，我将尝试询问服务提供商.

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.

谢谢.

推荐答案

由于压缩后响应的内容长度是无法预测的，因此先将其完全压缩在内存中，然后计算长度，然后流化压缩后，可能会非常昂贵且缓慢来自内存的响应，普通Web服务器将使用 Transfer-Encoding: chunked 没有一个Content-Length标头.

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: chunked without a Content-Length header.

由于它是本地HTTP客户端，因此听起来好像没有正确处理分块的请求.您必须确定Transfer-Encoding响应标头，如果它等于chunked，则必须将其解析为分块流.

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-Encoding response header and if it equals to chunked, then you have to parse it as a chunked stream.

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

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.

为节省所有繁琐的编码工作(可能还保存了本地HTTP客户端的剩余内容)，我强烈建议您查看

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.

这篇关于Tomcat gzip出现分块问题时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！