Cache-Control prosto wyjaśnione: co robią no-cache, no-store, max-age i s-maxage

Cache-Control określa, czy odpowiedź HTTP może zostać zapisana i kiedy wolno ponownie użyć zapisanej odpowiedzi. Szybkie drugie otwarcie strony nie dowodzi ani trafienia w pamięć podręczną, ani braku żądania sieciowego.

Podstawowa różnica: no-store zabrania zapisu w pamięciach podręcznych HTTP; no-cache dopuszcza zapis, lecz wymaga skutecznej walidacji przed ponownym użyciem. Żadna z tych reguł nie gwarantuje braku danych w innych częściach aplikacji.

Przechowywanie i świeżość to różne pojęcia

Prywatna pamięć podręczna HTTP działa na przykład w przeglądarce. Pamięć współdzielona, taka jak CDN lub proxy, obsługuje wielu klientów. Możliwych jest kilka warstw pamięci. Określenie „prywatna” opisuje rodzaj pamięci, a nie wyłączny dostęp jednej osoby do urządzenia.

Walidacja oznacza sprawdzenie na serwerze, czy zapisana odpowiedź jest nadal aktualna. Świeża odpowiedź może zwykle zostać użyta bez tego sprawdzenia, z uwzględnieniem pozostałych reguł. Nieświeża odpowiedź przekroczyła okres świeżości. Nie oznacza to usunięcia: kopia może pozostać do późniejszej walidacji. Z kolei brak miejsca może spowodować usunięcie jeszcze przed końcem tego okresu.

no-cache: sprawdzenie przed ponownym użyciem

Dyrektywa odpowiedzi Cache-Control: no-cache bez listy pól wymaga skutecznej walidacji przed ponownym użyciem zarówno w prywatnej, jak i współdzielonej pamięci. Zapis pozostaje opcjonalny.

Wartość ETag może wrócić w żądaniu jako If-None-Match; Last-Modified umożliwia sprawdzenie przez If-Modified-Since. Odpowiednia odpowiedź 304 Not Modified oszczędza ponowne przesłanie treści odpowiedzi. Żądanie i nagłówki odpowiedzi nadal przechodzą przez sieć. Zmieniona treść zwykle wymaga nowej pełnej odpowiedzi. Oszczędność zależy od rozmiaru treści i kosztu sprawdzenia.

no-store: reguła pamięci HTTP

Cache-Control: no-store zabrania pamięciom podręcznym HTTP zapisu tej odpowiedzi. Nowa reguła na serwerze źródłowym nie usuwa zdalnie wcześniejszych wpisów, jeśli nie nastąpił kolejny kontakt z serwerem.

Nie jest to ogólna gwarancja usunięcia danych ani poufności. Pamięć aplikacji oraz JavaScript Cache API wymagają osobnej obsługi; Cache API nie respektuje automatycznie nagłówków pamięci HTTP. Pamięć nawigacji wstecz/dalej przechowuje stan strony według odrębnych zasad przeglądarki. Chrome może pod określonymi warunkami umieszczać w tej pamięci niektóre strony z no-store.

max-age i s-maxage określają okres świeżości

max-age ustala okres świeżości w sekundach. s-maxage dotyczy pamięci współdzielonej i ma tam pierwszeństwo przed max-age oraz Expires. Poniższy umowny przykład dotyczy publicznej, niespersonalizowanej treści:

Cache-Control: public, max-age=60, s-maxage=300

Okres świeżości w przeglądarce wynosi 60 sekund, a w pamięci współdzielonej 300 sekund. Nie jest to gwarantowany czas przechowywania. Czas już spędzony w pamięciach wlicza się do wieku odpowiedzi. Przy max-age=300 oraz Age: 180 pozostaje około 120 sekund, pomniejszone o dalszy czas przesyłania i przechowywania.

must-revalidate zabrania ponownego użycia po utracie świeżości aż do skutecznej walidacji, także podczas awarii serwera źródłowego. s-maxage nakłada to ograniczenie również na pamięci współdzielone. Brak tych reguł nie oznacza dowolnej zgody na wydawanie nieświeżej treści.

private i public określają zakres pamięci

private bez listy pól zabrania przechowywania we współdzielonej pamięci, ale dopuszcza prywatną pamięć z zachowaniem pozostałych reguł. Dla odpowiedzi osobistej, którą wolno zachować lokalnie, lecz trzeba sprawdzić przed ponownym użyciem, przykładowa polityka wygląda tak:

Cache-Control: private, no-cache

Jeżeli już sam zapis HTTP jest niepożądany, właściwym ograniczeniem jest no-store. public może dopuścić wspólne przechowywanie, ale nie wymusza zapisu i nie uchyla równoczesnego zakazu, takiego jak no-store. Żadna z tych reguł nie zastępuje uwierzytelniania ani kontroli uprawnień.

Błędnie skonfigurowana pamięć współdzielona może ujawnić osobiste odpowiedzi. Ryzyko zależy od kluczy pamięci, ciasteczek, uwierzytelniania i reguł CDN; sam brak private nie dowodzi wycieku. Reguły dostawcy mogą nadpisać ustawienia serwera źródłowego. Potrzebne są zatem zarówno kontrola konfiguracji, jak i obserwacja odpowiedzi.

Nieświeże odpowiedzi wymagają ograniczeń

Dla publicznej treści, przy dopuszczalnym krótkim opóźnieniu, drugi umowny przykład ma postać:

Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=90

Pamięć obsługująca tę regułę może wydawać nieświeżą odpowiedź przez maksymalnie 30 dodatkowych sekund i jednocześnie próbować walidacji w tle. Pracę uruchamia żądanie. Nie ma gwarancji udanej aktualizacji ani świeżej odpowiedzi przy następnym żądaniu.

stale-if-error=90 dopuszcza odpowiedź nieświeżą od najwyżej 90 sekund przy odpowiednim błędzie, w tym HTTP 500, 502, 503 lub 504. To ograniczony mechanizm awaryjny, a nie bezterminowa ochrona przed awarią. Błąd aplikacji zwrócony ze statusem HTTP 200 nie należy do tych kodów. Obsługa i współdziałanie ze ściślejszymi regułami zależą od pamięci; przykład celowo pomija must-revalidate oraz s-maxage.

Co potwierdza kontrola nagłówków

Sprawdzarka nagłówków bezpieczeństwa HTTP wykonuje żądanie po stronie serwera i śledzi przekierowania w granicach działania narzędzia. Nie odtwarza zalogowanej sesji przeglądarki. Jedna odpowiedź nie dowodzi faktycznego zapisu, rozdzielenia kluczy pamięci ani działania wszystkich lokalizacji CDN. Cache-Control może też nie występować; wtedy mogą obowiązywać inne reguły albo okres świeżości może być szacowany na podstawie dostępnych informacji o odpowiedzi.

Rzetelna kontrola łączy nagłówki odpowiedzi, obserwację sieci w przeglądarce i konfigurację CDN. Istotne są status, Age, walidatory, wybrany klucz pamięci oraz źródło powtórnej odpowiedzi: RAM, dysk lub sieć. Odpowiedzi bez logowania i po zalogowaniu wymagają osobnych prób. Powtarzające się pola nagłówków powinny zostać sprawdzone w oryginalnej odpowiedzi sieciowej, nie tylko w skróconym widoku narzędzia.