1

HTTPリクエストをサーバーに送信しています。サーバーはHTTPレスポンスコード=200（OK）の空白のレスポンスを合法的に返します。

しかし、これにより、以下のマークされた行が：をスローしEOFExceptionます。

InputStream responseStream = httpURLConnection.getInputStream();
final String contentEncoding = this.connection.getContentEncoding();
if ("gzip".equalsIgnoreCase(contentEncoding)) {
    responseStream = new GZIPInputStream(responseStream); // throws EOFException
}

これを防ぐための明白な方法があるかもしれませんが、私はそれを見つけることができません。GZIPInputStreamを作成する前に、connection.getContentLength() > 0またはそのようなものをチェックする必要がありますか？responseStream.available() > 0これらはどちらも完全に正しいようには見えず、サンプルコードフラグメントで類似したものに出くわしたことはありません...

4

4 に答える 4

3

おそらくconnection.getContentLength（）>0のようなものをチェックする必要があります

はい。

またはresponseStream.available（）> 0

絶対にありません。available（）== 0はEOFの有効なテストではなく、Javadocは明示的にそう言っています。

于 2013-02-11T17:36:49.917 に答える
1

サーバーは200ではなくHTTPコード204（コンテンツなし）を返す必要がありますか？であるHEADリクエストを除いて。Httpステータスコードの定義を参照してください

それとは別に、完全に準拠していないサーバー実装のように見えるものを回避するためにチェックするか、例外をキャッチして、送信したリクエストのタイプに応じて適切なアクションを決定することができます。

于 2013-02-11T17:28:09.360 に答える
1

あなたの質問から私が理解しているのは200、サーバーから応答を受け取るたびに、この例外が一貫してスローされているということです。

がオプションでない場合は、ストリームに実際に何かが含まれていることを意味しますが、ストリームに読み取り可能なバイトがあると述べているresponseStream.available() > 0ため、そのストリームは不完全であるか、他の手段で途中で終了しているようです。available

アップデート

あなたのコメントに基づいて（そしてInputStream、まったくの好奇心から再びのドキュメントを読んだ後）、私もconnection.getContentLength() > 0行く方法だと信じています。Java 7を使用している場合は、直接connection.getContentLengthLong()返されるため、タフな方が優先されます。long

ドキュメントが何について言っているかを考えるとInputStream#available：

クラスInputStreamで使用可能なメソッドは、常に0を返します。

と

InputStreamの一部の実装はストリーム内の合計バイト数を返しますが、多くは返さないことに注意してください。このメソッドの戻り値を使用して、このストリーム内のすべてのデータを保持することを目的としたバッファーを割り当てることは決して正しくありません。

これにより、そのチェックがオプションとして破棄されます。

于 2013-02-11T17:31:11.857 に答える
0

何かが足りない場合を除いて、定義上、Content-Encoding「gzip」を使用した応答を空にすることはできません。

于 2016-11-09T16:25:37.883 に答える