6

データソースサービスの1つで問題が発生しています。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圧縮された要求を送信するように要求しているときに、完全な応答を送信しないことがよくあることです。応答を受信し、最後のチャンクが受信されたことを確認しましたが、解凍した後、応答が部分的であることがわかりました。リクエストヘッダーでgzipをオフにした場合のこのような動作は見たことがありません。

だから私の質問は：それは一般的なTomcatの問題ですか？多分それの1つは圧縮をしているmodですか？それとも、ある種のプロキシの問題でしょうか？tomcatのバージョンや使用されているgzipmodについてはわかりませんが、お気軽にサービスプロバイダーに問い合わせてみます。

ありがとう。

4

1 に答える 1

3

gzipで圧縮された応答のコンテンツの長さは予測不可能であり、最初にメモリ内で完全に圧縮してから長さを計算してからメモリからgzipで圧縮された応答をストリーミングするのはコストがかかり、時間がかかる可能性があるため、平均的なWebサーバーはヘッダーなしでチャンクで送信します。Transfer-Encoding: chunked Content-Length

自社開発のHTTPクライアントであるため、チャンクされたリクエストを正しく処理していないように聞こえます。応答ヘッダーを決定する必要がTransfer-Encodingあり、それがに等しい場合はchunked、チャンクストリームとして解析する必要があります。

前述のHTTP仕様のリンクとウィキペディアから、チャンクストリームを解析する方法を学ぶことができます。各チャンクは、16進数でチャンクの長さを示すヘッダー、次にCRLF、次に実際のチャンクコンテンツ、次にCRLFで構成されます。これは、チャンクの長さを示すヘッダーを持つチャンクまで繰り返され0ます。チャンクを個別に解凍してから、接着する必要があります。

面倒なコーディング作業をすべて保存するために（おそらく、自家製のHTTPクライアントの残りの部分も）、ApacheHttpComponentsクライアントを確認することを強くお勧めします。

于 2010-04-07T22:11:23.167 に答える