Z RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
no-cache
Jeśli dyrektywa no-cache nie określa nazwy pola, pamięć podręczna NIE MOŻE używać odpowiedzi w celu spełnienia kolejnego żądania bez pomyślnej ponownej walidacji z serwerem pochodzenia. Dzięki temu serwer pochodzenia może zapobiegać buforowaniu nawet przez pamięci podręczne, które zostały skonfigurowane do zwracania nieaktualnych odpowiedzi na żądania klientów.
Dlatego nakazuje agentom ponowne zweryfikowanie wszystkich odpowiedzi.
W porównaniu z
musi ponownie zweryfikować
Gdy dyrektywa must-revalidate jest obecna w odpowiedzi otrzymanej przez pamięć podręczną, ta pamięć podręczna NIE MOŻE używać wpisu po tym, jak stanie się nieaktualny, aby odpowiedzieć na kolejne żądanie bez uprzedniego ponownego zweryfikowania go z serwerem pochodzenia
Dlatego kieruje agentów do ponownej walidacji nieaktualnych odpowiedzi.
W szczególności w odniesieniu do tego no-cache, czy w ten sposób programy użytkownika empirycznie traktują tę dyrektywę?
Jaki jest sens, no-cachejeśli jest must-revalidatei max-age?
Zobacz ten komentarz:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
no-cache
Chociaż ta dyrektywa brzmi tak, jakby instruowała przeglądarkę, aby nie buforowała strony, istnieje subtelna różnica. Dyrektywa „no-cache”, zgodnie z RFC, mówi przeglądarce, że powinna przeprowadzić ponowną weryfikację z serwerem przed wyświetleniem strony z pamięci podręcznej. Ponowna walidacja to zgrabna technika, która pozwala aplikacji zachować szerokość pasma. Jeśli strona zapisana w pamięci podręcznej przeglądarki nie uległa zmianie, serwer po prostu sygnalizuje to przeglądarce, a strona jest wyświetlana z pamięci podręcznej. Dlatego przeglądarka (przynajmniej w teorii) przechowuje stronę w swojej pamięci podręcznej, ale wyświetla ją dopiero po ponownej walidacji z serwerem. W praktyce IE i Firefox zaczęły traktować dyrektywę no-cache tak, jakby instruowała przeglądarkę, aby nawet nie buforowała strony. Zaczęliśmy obserwować to zachowanie około rok temu.
Czy ktoś ma w tej sprawie coś bardziej oficjalnego?
Aktualizacja
Dyrektywa must-revalidate powinna być używana przez serwery wtedy i tylko wtedy, gdy brak walidacji żądania w reprezentacji może skutkować nieprawidłową operacją, taką jak cicha niezrealizowana transakcja finansowa.
To jest coś, czego nigdy nie wziąłem sobie do serca. RFC mówi, że nie wolno lekceważyć konieczności ponownej walidacji. Chodzi o to, że w przypadku usług internetowych musisz spojrzeć negatywnie i założyć najgorsze dla nieznanych aplikacji klienckich. Każdy przestarzały zasób może spowodować problem.
I coś, co właśnie rozważałem, bez Last-Modified lub ETagów, przeglądarka może ponownie pobrać cały zasób. Jednak w przypadku ETagów zauważyłem, że Chrome przynajmniej wydaje się ponownie sprawdzać poprawność przy każdym żądaniu. Co sprawia, że obie te dyrektywy są wątpliwe lub przynajmniej źle nazwane, ponieważ nie mogą poprawnie zweryfikować poprawności, chyba że żądanie zawiera również inne nagłówki, które i tak powodują „zawsze ponownie waliduj”.
Chcę tylko wyjaśnić ten ostatni punkt. Po prostu ustawiając, must-revalidateale bez uwzględnienia ETag lub Last-Modified, agent może tylko ponownie pobrać zawartość, ponieważ nie ma nic do wysłania na serwer do porównania.
Jednak moje testy empiryczne wykazały, że kiedy ETag lub zmodyfikowane dane nagłówka są zawarte w odpowiedziach, agenci i tak zawsze dokonują ponownej walidacji, niezależnie od obecności must-revalidatenagłówka.
Tak więc must-revalidatechodzi o wymuszenie `` pominięcia pamięci podręcznej '', gdy się zestarzeje, co może się zdarzyć tylko wtedy, gdy ustawisz czas życia / wiek, więc jeśli must-revalidatejest ustawiony na odpowiedź bez wieku lub innych nagłówków, w rzeczywistości staje się odpowiednikiem no-cacheod odpowiedź zostanie natychmiast uznana za nieaktualną.
- Więc w końcu zaznaczę odpowiedź Gili!