web-dev-qa-db-ja.com

java.net.ProtocolException：予期しないストリームの終わり

奇妙な問題に直面しており、デバッグできません。データのストリームをアップロードするためのロジックを実装し、同じためにVolleyを使用しています。HurlStack、addBodyIfExists apiでロジックを少しカスタマイズして、タイプ「application/octet」の本体をカスタマイズしました-stream」も扱えます。

私のロジックは、進行状況をユーザーに投稿することです。これにより、UIを更新して、アップロード中のユーザーの進行状況を示すことができます。

            int toRead = length; // File length
            byte[] data = new byte[4096];
            connection.setDoOutput(true);
            if(length != -1) {
                connection.setFixedLengthStreamingMode(length);
            } else {
                connection.setChunkedStreamingMode(4096);
            }

            OutputStream os;
            int i;
            int count;

            os = connection.getOutputStream();
            int progress= 0;

               try {
                    for(i = 0; (count= is.read(data)) > 0; ++i) { // is, is not null and contains a valid input stream
                        os.write(data, 0, count); // at this line am getting unexpected end of stream
                        progress+= count;
                        if(i % 20 == 0) {
                            rs.deliverProgress(progress, 0L);
                            progress= 0;
                        }
                    }

                    os.flush();
                } finally {
                    if(is != null) {
                        is.close();
                    }

                    if(os != null) {
                        os.close();
                    }

                }

上記のコードを実行すると、これが得られますが、出力ストリームはnullではなく、入力ストリームもそうではありません。読み取りループ自体の最初の反復で失敗し、4096バイトを読み取ってから同じものを書き込もうとしていることがわかります。

Java.net.ProtocolException: unexpected end of stream
            at com.Android.okhttp.internal.http.HttpConnection$FixedLengthSink.close(HttpConnection.Java:326)
            at com.Android.okio.RealBufferedSink.close(RealBufferedSink.Java:174)
            at com.Android.okio.RealBufferedSink$1.close(RealBufferedSink.Java:142)

上記のデバッグの手助けは彼に高く評価されます。

androidandroid-volleyokhttp
13
Techfist

これ が役立つかもしれません：

この例外は、予想されるバイト数（通常は応答のcontent-lengthヘッダーで設定される）が応答の実際のデータより大きい場合にFixedLengthInputStreamによってスローされます。 content-lengthヘッダーが正しいことを確認してください。 （コンテンツの長さに独自の値を指定する場合は、それが正しいことを確認してください。）

入力ストリームを設定するコードを確認すると役立ちます。

5
Saeid