6

この HttpRetryException 問題に対処した他の人のために多くの場所を検索しましたが、私が見つけたすべての人が、私が使用していない CXF と呼ばれるいくつかの apache サービスで問題に遭遇しました。私が使用しているのは、java.net.HttpURLConnection です。接続を作成し、「認証」に setRequestProperty を使用し、出力ストリームを取得し、大量のバイトを書き込んでから、応答入力ストリームを読み取ろうとします。ほとんどの場合、これは機能しますが、上記の例外が発生することがあります。メモリに保存できるよりも大きなファイルを書き込む必要がある場合があるため、ストリーミングを避けることはできません。とにかく、検索結果のほとんどは、それが本当の問題ではないことを示しています。彼らは通常、次のような解決策を提供します。bindingProvider.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "username"); bindingProvider.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "password"); 私は HttpURLConnection で cxf やその他のラッパーを使用しておらず、参照するサービスやバインディング プロバイダーもありません。また、setRequestProperty で設定されたユーザー名とパスワードは、ほとんどの場合、認証に問題なく機能します。エラーを確実に再現するために必要な特定の前提条件を述べたいと思いますが、これまでのところ、ヒットまたはミスしています。

4

1 に答える 1

10

JDKでスローされる場所は1つだけです。これはjava.net.HttpRetryException、HttpURLConnectionが使用され、リダイレクトをたどろうとする場合です(sun.net.www.protocol.http.HttpURLConnection.followRedirect()を参照)。

Location:したがって、基本的に、サーバーは3xxのHTTPステータスコード(304と306を除く)で応答し、 HTTPヘッダーで指定された場所をたどろうとします。ただし、ストリーミングが有効になっているため、リダイレクトを追跡できません。

設定してみてくださいjava.net.HttpURLConnection.setInstanceFollowRedirects(false)

そもそもサーバーがHTTPリダイレクトを送信している理由を確認したいのですが。あなたの説明から、HTTP POSTを使用してより大きなアップロードを実行していると理解していますが、それは正しいですか?

于 2010-12-28T00:33:01.300 に答える