Ich benutze Retrofit, konfiguriert OkHttp mit einem Cache zu verwenden.
Ich nenne das api: Ссылка , das sowohl einen Etag als auch einen Cache-Control: public, max-age=60, s-maxage=60 Header zurückgibt.
Ich erledigte zwei Anfragen in weniger als 60 Sekunden, so dass ich erwartete, dass die zweite überhaupt kein Netzwerk ausführen und den Cache nach der Anweisung Cache-Control verwenden würde. Aber das sehe ich nicht.
Ich vermute, das liegt daran, dass die Etag -Direktive Vorrang hat?
Ist das korrekt / normal / erwartet?
RFC2068 Hypertext Transfer Protocol - HTTP / 1.1 , das 1997 veröffentlicht wurde, enthält sowohl ETag als auch Cache-Control Headers. Spätere Dokumente, RFC2616 und RFC7232 erweitern beide den Header ETag und wie er mit If-None-Match verwendet werden kann.
RFC2616, 13.3 Validierungsmodell enthält die Antwort auf Ihre Frage:
Wenn ein Cache einen veralteten Eintrag hat, den er als a verwenden möchte Antwort auf eine Anfrage des Kunden, muss es zuerst mit dem Ursprung überprüfen Server (oder möglicherweise ein Zwischenspeicher mit einer neuen Antwort) an Prüfen Sie, ob der zwischengespeicherte Eintrag noch verwendbar ist. Wir nennen das "validieren" der Cache-Eintrag.
Anschließend werden Validierungsmodelle aufgelistet, einschließlich Entity-Tag (ETag) -Cache-Validatoren und Last-Modified-Daten. Ein veralteter Cache-Eintrag ist einer, bei dem der maxage oder ein anderer Ablaufmechanismus für diese Ressource aufgetreten ist.
Das Verhalten Ihres Systems ist also unerwartet. Es kann sich lohnen, Inhalte mit und ohne den ETag-Header zu testen, um zu überprüfen, ob der lokale Cache überhaupt funktioniert.
Haben Sie beim Nachrüsten das Caching richtig eingerichtet? Etwas wie:
%Vor%Das ist trivial, wenn Sie es wissen, aber Sie haben Ihre Implementierung nicht erwähnt
Tags und Links android retrofit2 http-caching okhttp3