問題タブ [okhttp]

私は Google Volley と Gson を使用してアプリを作成し、OkHttp を HTTP スタックとして使用して REST サービスと通信しています。それはほとんどの場合うまくいきますが、アプリを一時停止してアプリに戻ると、HTTP リクエストはこの例外で機能しません:

それはランダムに起こります。アプリケーションを一時停止するたびにではありません。どこから始めればいいのか本当にわかりません。

認証済みの HTTPS 接続で OkHttpResponseCache を使用した人はいますか? コンテンツがキャッシュから 2 回目に提供されると、正しいコンテンツではなくガベージが返されるという、この奇妙な動作に直面しています。

例として使用しているサービスは、HTTP 基本認証で保護され、HTTPS 経由でアクセスされます。must-revalidate レスポンス ヘッダーを追加して、キャッシュがレスポンスを保存できるようにしました。キャッシュ検証のメカニズムとして ETag を使用します。

最初のキャッシュされた応答に対して完全に機能します。

1 - 初めてサービス呼び出しを行うと、サーバーは 200 OK を返します。レスポンス キャッシュのソース コードをデバッグすると、put() メソッド (ファイル ストアに保存されます) に渡された場合にレスポンスを確認できました。

2 - 2 番目の要求が行われます。サーバーがヒットし、304 応答を返します。キャッシュ ヘッダーとステップ デバッグをチェックすると、サーバーが実際に 304 を返したことが確認されました。奇妙な動作が 1 つあります。2 番目の応答 (現在はキャッシュによって提供されます) で、ETag ヘッダーに重複した値が含まれるようになりました (単一の値ではなく、この値がリストに 2 回含まれています)。

3 - 3 番目のリクエストを行います。上記と同じ動作、同じ ETag 値の「重複」ですが、入力ストリームを取得すると、正しい json テキストではなく、ゴミが表示されます (内部に尋問がある黒いひし形の束のように)。

何か間違ったことをしているかどうかはわかりません (キャッシュの構成時)。これがエンコーディングの問題なのか、それともキャッシュがファイル ストアを更新しようとして入力を台無しにしたのかはわかりません。最初のキャッシュ応答 (2 回目の試行) の後、2 番目の ETag 値が存在するとヘッダーが無効になり、キャッシュが応答をもう一度保存しようとして、めちゃくちゃになってしまうのではないかと思います。まだ確認するためにデバッグを進めることができませんでした。

ガベージテキストをUTF-8、16、ASCII、ISOで「翻訳」しようとしましたが、役に立ちませんでした。HTTPS の代わりに HTTP を使用してみましたが、同じ動作が得られました。

誰かが似たようなことに遭遇し、それを解決できましたか? キャッシュのバグですか、それとも何か間違ったことをしている可能性がありますか?

Okhttp とレトロフィットを使用したアプリを作成しました。いくつかの不規則な有線動作を除いて、すべて正常に動作します。このニュース アプリでは、複数のセクションのフィード ダウンロード リクエストをトリガーします。ときどきリクエストが応答を返すことはありません (例外をスローすることさえありません)。

潜在的な容疑者を見つけようとしましたが、何も見つかりませんでした。ddms の「スレッド」から確認できる唯一のことは、多くのスレッドが「モニター」状態にあることです (スクリーンショットを参照してください)。

編集： レトロフィットのための別の通常のスレッドダンプ：

レトロフィット構成は次のとおりです。

任意のアイデア、誰かが同様の問題を経験していますか?

Retrofit を使用して基本的な POST リクエストを実行し、リクエストに基本的な @Body を提供しています。

Retrofit のインターフェイスを構築するときは、独自のカスタム OkHttpClient を提供しています。それに対して行っているのは、独自のカスタム認証を追加することだけです。

これは、OKHttp を使用して直接リクエストを送信したり、レトロフィットを使用して他の GET リクエストを送信したりする場合にうまく機能しますが、レトロフィットを使用して POST リクエストを実行すると、次のエラーが発生します。

私はそれで遊んだ。認証を削除し、認証を必要としないサーバーを指すと、正常に動作します。

1. だから情報を発信しているに違いない。
2. 認証チャレンジ リクエストを取得します。
3. チャレンジリクエストにお応えします。
4. リクエストを再送信しようとすると、エラーがスローされます。

これを回避する方法がわかりません。どんな助けでも素晴らしいでしょう。

アプリケーションの 1 つでレトロフィットとokhttpを使用しています。

Retrofit のデフォルトの動作について、適切な説明を見つけることができません。

Okhttp がクラス パス上にある場合は、自動的に使用されます。しかし、私が見る限り、デフォルトの HttpResponseCache は null です。

Retrofit と Okhttp でキャッシュを明示的に有効にする必要がありますか?