認証済みの 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 を使用してみましたが、同じ動作が得られました。
誰かが似たようなことに遭遇し、それを解決できましたか? キャッシュのバグですか、それとも何か間違ったことをしている可能性がありますか?