Idealne nagłówki kontroli pamięci podręcznej HTTP dla różnych typów zasobów

82

Chcę znaleźć minimalny zestaw nagłówków, który będzie działał ze „wszystkimi” pamięciami podręcznymi i przeglądarkami (także przy korzystaniu z protokołu HTTPS !)

W mojej witrynie internetowej będę mieć trzy rodzaje zasobów:

(1) Pamięć podręczna na zawsze (publiczna / równa dla wszystkich użytkowników)

Przykład: 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( automatycznie generowany przez GWT )

  • Pliki te automatycznie otrzymują nową nazwę, gdy zmieniają zawartość (na podstawie MD5).

  • Powinny być buforowane jak najwięcej, nawet przy korzystaniu z HTTPS (więc zakładam, że powinienem ustawić Cache-Control: public, szczególnie dla Firefoksa?)

  • Nie powinny wymagać, aby klient odbył podróż w obie strony do serwera w celu sprawdzenia, czy zawartość uległa zmianie.

(2) Okazjonalne zmiany (publiczne / równe dla wszystkich użytkowników)

Przykłady: index.html, mymodule.nocache.js

  • Te pliki zmieniają swoją zawartość bez zmiany adresu URL, gdy wdrażana jest nowa wersja witryny.

  • Można je przechowywać w pamięci podręcznej, ale prawdopodobnie za każdym razem wymagają one podróży w obie strony, aby ponownie je zweryfikować.

(3) Indywidualne dla każdego wniosku (prywatne / specyficzne dla użytkownika)

Przykład: odpowiedzi JSON

  • Zasoby te nigdy nie powinny być buforowane w postaci niezaszyfrowanej na dysku pod żadnym pozorem. (Może z wyjątkiem kilku konkretnych żądań, które można będzie przechowywać w pamięci podręcznej).

Mam ogólny pomysł, których nagłówków prawdopodobnie użyłbym dla każdego typu, ale zawsze jest coś, czego mogę przegapić.

http caching https http-headers Chris Lercher
źródło
Dziękuję za odpowiedzi, komentarze i linki. Wciąż trochę eksperymentuję, ale myślę, że uda mi się znaleźć rozwiązanie!
Chris Lercher
2
Osiągnięcie # 3 jest generalnie niemożliwe.
EricLaw
Zobacz także: stackoverflow.com/questions/6491789/…
Mikko Rantalainen

Odpowiedzi:

91

Prawdopodobnie użyłbym tych ustawień:

  1. Cache-Control: max-age=31556926- Reprezentacje mogą być przechowywane w dowolnej pamięci podręcznej. Reprezentację zapisaną w pamięci podręcznej należy uważać za świeżą przez 1 rok:

    Aby oznaczyć odpowiedź jako „nigdy nie wygasa”, serwer pochodzenia wysyła datę wygaśnięcia w przybliżeniu jeden rok od momentu wysłania odpowiedzi. Serwery HTTP / 1.1 NIE POWINNY wysyłać. Wygasa po upływie ponad jednego roku.

  2. Cache-Control: no-cache- Reprezentacje mogą być buforowane przez dowolną pamięć podręczną. Ale pamięci podręczne muszą przesłać żądanie do serwera pochodzenia w celu weryfikacji przed zwolnieniem kopii z pamięci podręcznej.
  3. Cache-Control: no-store - Pamięci podręczne nie mogą buforować reprezentacji w żadnych warunkach.

Więcej informacji można znaleźć w samouczku Marka Nottinghama dotyczącym buforowania .

Gumbo
źródło
1
@Gumbo: Jedno jestem pewien, że muszę ustawić jako publiczne , kiedy chcę, aby Firefox 3+ buforował pliki publiczne na dysku podczas korzystania z HTTPS: stackoverflow.com/questions/174348/ ...
Chris Lercher
2
Niektóre przeglądarki, takie jak IE, zaczynają traktować Cache-Control: no-cache tak, jakby to było bez magazynu. Wprawdzie nie jest to zgodne z RFC, ale świadomie ma to na celu „naprawienie” błędu popełnionego przez WIELU polegających na używaniu no-cache, aby zapobiec przechowywaniu poufnych danych w postaci niezaszyfrowanej na dysku.
AviD,
1
@chris_l, trafiłem na ten link: palisade.plynt.com/issues/2008Jul/cache-control-attributes . Nie pamiętam, jak zachowywały się poprzednie wersje, chociaż myślę, że IE7 też to robił.
AviD,
2
Ponadto Firefox nie wymaga już PUBLIC w Cache-Control do buforowania zasobów HTTPS. Ale ogólnie najlepiej jest po prostu przetestować swoją witrynę, obserwując ruch, np. Z Fiddlerem.
EricLaw,
3
Nie zaleca się ustawiania wartości kontrolnej pamięci podręcznej na 100 lat. Po pierwsze, specyfikacja zaleca maksymalnie 1 rok. Po drugie, każda wartość powyżej 68 lat skutkuje natychmiastowym wygaśnięciem dla IE8 i niższych: blogs.msdn.com/b/ieinternals/archive/2010/01/26/…
EricLaw Kwietnia
-2

Przypadki pierwszy i drugi to w rzeczywistości ten sam scenariusz. Należy ustawić, Cache-Control: publica następnie wygenerować adres URL zawierający numer kompilacji / wersję witryny, aby mieć niezmienne zasoby, które potencjalnie mogą trwać wiecznie. Chcesz także ustawić Expiresnagłówek rok lub więcej w przyszłości, aby klient nie musiał wystawiać kontroli świeżości.

W przypadku 3 dla maksymalnej elastyczności możesz wykonać wszystkie poniższe czynności: 

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"
Andrew L.
źródło
Różne adresy URL dla nowych kompilacji prawdopodobnie nie wchodzą w grę: a) Zmusiłoby to klienta do ponownego pobrania plików zapisywanych na zawsze w pamięci podręcznej. Otrzymują unikalne nazwy, aby tego uniknąć. b) Główny adres URL mojej witryny powinien być po prostu https://www.example.com/c) Chcę, aby zakładki zawsze odnosiły się do najnowszej wersji mojej witryny (wyobraź sobie, że zakładki do pytania o przepływie stosu zawierałyby numer kompilacji witryny).
Chris Lercher
Cześć Chris, To podejście jest zwykle używane w przypadku zasobów CSS i JS, a nie dokumentów. Zgadzam się, że nie ma to zastosowania do identyfikatorów dokumentów, w takim przypadku należy po prostu ustawić publiczną kontrolę pamięci podręcznej, Ostatnia modyfikacja i etag w nagłówkach, co spowoduje za każdym razem sprawdzenie świeżości i tylko 304 zostanie odesłany, jeśli nie ma zmian od ostatniego pobrania. Alternatywnie, możesz pobrać rzeczywistą dynamiczną zawartość każdej strony za pośrednictwem JS, aby zachować adres URL, jednocześnie umożliwiając efektywne buforowanie.
Andrew L
Tak, to prawie sposób, GWT radzi sobie z tym za mnie: Mój index.html (zmieniany od czasu do czasu) zawiera mymodule.nocache.js (zmieniający się od czasu do czasu), który automatycznie dołącza poprawne pliki, które można na zawsze buforować (duże części js, zarządzane przez GWT pakiety obrazów, ...) Jedyne, co mi pozostawia, to ustawienie poprawnych nagłówków http dla każdego typu. Chcę ograniczyć te nagłówki do minimum, ponieważ stanowią one duży procent wolumenu transferu. Czy potrzebuję więc np. Zarówno Last-Modified, jak i ETag itp.?
Chris Lercher
„Wygasa” w rzeczywistości musi być datą, a nie liczbą 0. Powinien mieć taką samą wartość jak nagłówek „Data”. Widzieć mnot.net/cache_docs
Luke Hutchison