Z RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

bez pamięci podręcznej

Jeśli dyrektywa bez pamięci podręcznej nie określa nazwy pola, wówczas pamięć podręczna NIE MOŻE używać odpowiedzi do spełnienia kolejnego żądania bez pomyślnego ponownego zatwierdzenia z serwerem pochodzenia. Umożliwia to serwerowi źródłowemu zapobieganie buforowaniu nawet przez bufory skonfigurowane do zwracania nieaktualnych odpowiedzi na żądania klientów.

Więc kieruje agentami do ponownego sprawdzeniawszystko odpowiedzi.

Porównano to do

must-revalidate

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ę przestarzała, aby odpowiedzieć na kolejne żądanie bez uprzedniego ponownego zatwierdzenia go na serwerze pochodzenia

Więc kieruje agentami do ponownego sprawdzenianieświeży odpowiedzi.

Szczególnie w odniesieniu dono-cache, czy tak właśnie działają aplikacje klienckie, empirycznie traktując tę ​​dyrektywę?

O co chodzino-cache jeśli jestmust-revalidate imax-age?

Zobacz ten komentarz:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

bez pamięci podręcznej

Chociaż ta dyrektywa brzmi tak, jakby instruowała przeglądarkę, aby nie buforowała strony, istnieje subtelna różnica. Dyrektywa „bez pamięci podręcznej”, zgodnie z RFC, informuje przeglądarkę, że należy ją ponownie zweryfikować na serwerze przed podaniem strony z pamięci podręcznej. Sprawdzanie poprawności to zgrabna technika, która pozwala aplikacji zachować szerokość pasma. Jeśli strona, którą buforowała przeglądarka, nie uległa zmianie, serwer sygnalizuje to tylko przeglądarce, a strona jest wyświetlana z pamięci podręcznej. Stąd przeglądarka (przynajmniej teoretycznie) przechowuje stronę w pamięci podręcznej, ale wyświetla ją dopiero po ponownym zatwierdzeniu na serwerze. 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. Podejrzewamy, że zmiana ta była spowodowana powszechnym (i niepoprawnym) stosowaniem tej dyrektywy w celu zapobiegania buforowaniu.

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 na reprezentacji może spowodować niepoprawne działanie, takie jak cicho niezrealizowana transakcja finansowa.

To jest coś, czego nigdy dotąd nie wziąłem sobie do serca. RFC mówi, że nie używać lekko rewalidacji. Chodzi o to, że w przypadku usług internetowych musisz mieć negatywny pogląd i przyjąć najgorsze dla nieznanych aplikacji klienckich. Każdy nieświeży zasób może spowodować problem.

I coś, co właśnie rozważałem, bez Last-Modified lub ETags, przeglądarka może ponownie pobrać cały zasób. Jednak z ETagami zauważyłem, że Chrome wydaje się przynajmniej sprawdzać poprawność przy każdym żądaniu. Co powoduje, że obie te dyrektywy są dyskusyjne lub przynajmniej słabo nazwane, ponieważ nie mogą poprawnie rewalidować, chyba że żądanie zawiera także inne nagłówki, które powodują „zawsze rewaliduj”.

Chcę tylko wyjaśnić ten ostatni punkt. Po prostu ustawiającmust-revalidate ale nie zawiera ani ETag, ani Last-Modified, agent może ponownie pobrać zawartość, ponieważ nie ma nic do wysłania do serwera w celu porównania.

Jednak moje testy empiryczne wykazały, że gdy ETag lub zmodyfikowane dane nagłówka są uwzględniane w odpowiedziach, agenci i tak zawsze sprawdzają poprawność, niezależnie od obecnościmust-revalidate nagłówek.

Więc o co chodzimust-revalidate jest wymuszanie „obejścia pamięci podręcznej”, gdy przestanie działać, co może się zdarzyć tylko wtedy, gdy ustawisz czas życia / wiek, a więc jeślimust-revalidate jest ustawiony na odpowiedź bez wieku lub innych nagłówków, skutecznie staje się równoważnyno-cache ponieważ odpowiedź zostanie uznana za natychmiastowo nieaktualną.

- Więc zamierzam wreszcie zaznaczyć odpowiedź Gili!