Maksymalna wartość nagłówka kontroli pamięci podręcznej w HTTP

Używam Amazon S3 do obsługi zasobów statycznych dla mojej witryny. Chcę, aby przeglądarki przechowywały te zasoby w pamięci podręcznej tak długo, jak to możliwe. Jakie nagłówki metadanych należy dołączyć do zasobów

Cache-Control: max-age=???

— Casey Flynn
źródło

możliwa wartość maksymalnego wieku zależy od przeglądarki / wersji i dowolnego serwera proxy w drodze ... AFAIK nie ma prawdziwego standardu / specyfikacji, więc każda wartość byłaby domysłem ...

— Yahia

Odpowiedzi:

120

Ogólnie zaleca się jeden rok jako standardową wartość maksymalną. Zobacz RFC 2616 :

Aby oznaczyć odpowiedź jako „nigdy nie wygasa”, serwer pochodzenia wysyła datę ważności 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.

Chociaż dotyczy to starszego expiresstandardu, sensowne jest stosowanie go cache-controlrównież w przypadku braku jakichkolwiek wyraźnych wytycznych dotyczących norm. Jest tak długi, jak i tak generalnie potrzebujesz, a wybranie dowolnej dłuższej wartości może zepsuć niektórych klientów użytkownika. Więc:

Cache-Control: max-age=31536000

— mahemoff
źródło

Zastanów się, czy nie przechowywać go „tak długo, jak to możliwe”, a zamiast tego zadowalać się tak długo, jak to jest rozsądne. Na przykład jest mało prawdopodobne, że będziesz musiał przechowywać go w pamięci podręcznej dłużej niż powiedzmy 10 lat ... mam rację?

Dokument RFC omawia max-age tutaj: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3

Eric Lawrence mówi, że przed IE9 Internet Explorer traktowałby jako przestarzały każdy zasób z Cache-Control: wartość max-age powyżej 2147483648 (2 ^ 31) sekund, około 68 lat ( http://blogs.msdn.com/b /ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx ).

Oczywiście inne programy użytkownika będą się różnić, więc ... spróbuj wybrać liczbę, która prawdopodobnie (a nie prawdopodobna!) Spowoduje przepełnienie. Maksymalny wiek większy niż 31536000 (jeden rok) nie ma większego sensu i nieoficjalnie jest to uważane za rozsądną wartość maksymalną.

— Geoffrey McGrath
źródło

Właściwie szukam konkretnych nagłówków do wysłania. Mam mechanizm wbudowany w moją witrynę internetową, który zmienia adres URL pliku, aby wskazywał inną nazwę pliku, jeśli muszę wprowadzić zmianę, a odwiedzający go zobaczą. Potrzebuję tylko przykładu określonych nagłówków do wysłania, aby przeglądarki buforowały te zasoby w nieskończoność.

— Casey Flynn,

Cache-Control: max-age = 31536000 będzie buforować go przez 1 rok, co jest zalecane dla max.

— EricLaw

@Geoffrey: Myślę, że nie wiesz, co buduje Casey. Mówi po prostu, że zmieni adres URL, do którego odwołuje się w swoich znacznikach, gdy zmieni się wersja. Jest to sprawdzona metoda stosowana w większości najpopularniejszych witryn.

— EricLaw,

@Geoffrey Czy jesteś pewien, że to „ponad 2147483648”? Myślałem, że to „ponad 2147483647”?

— Pacerier

Osoby, które stworzyły rekomendację dotyczącą maksymalnie 1-rocznego buforowania, nie przemyślały tego właściwie.

Po pierwsze, jeśli odwiedzający jest obsługiwany nieaktualny plik z pamięci podręcznej, dlaczego miałoby przynosić jakąkolwiek korzyść, gdyby nagle załadował nową wersję po 1 roku? Jeśli plik ma 1 rok TTL, z funkcjonalnego punktu widzenia, oznacza to oczywiście, że plik nie jest przeznaczony do zmiany w ogóle.

Po co więc potrzebować więcej niż 1 rok?

1) Dlaczego nie? Nie ma żadnego celu na serwerze, aby powiedzieć przeglądarce odwiedzających "hej, ten plik ma 1 rok, może warto sprawdzić, czy został zaktualizowany".

2) usługi CDN. Większość sieci dostarczania treści używa nagłówka pamięci podręcznej do decydowania o tym, jak długo plik ma być efektywnie obsługiwany z serwera granicznego. Jeśli masz 1 rok kontroli pamięci podręcznej dla plików, w pewnym momencie zacznie on ponownie żądać niezmienionych plików z serwera źródłowego, a pamięć podręczna krawędzi będzie musiała zostać całkowicie ponownie wypełniona, powodując wolniejsze ładowanie dla klienta i niepotrzebne wezwania do pochodzenia.

Jaki jest sens posiadania maksymalnie 1 roku? Jakie przeglądarki dławią się kwotą wyższą niż 31536000?

— suncat100
źródło

1 rok to wieczność w dobie internetu. Dodatkowo, jeśli poważnie podchodzisz do buforowania, poradzisz sobie (oprócz kontroli pamięci podręcznej) z mechanizmem ostatniej modyfikacji i / lub etag. Więc nawet te ponowne żądania rok później nie zaszkodzą przepustowości (304 bez modyfikacji)

— redben

1 rok to nie wieczność, kiedy twoje obrazy NIGDY nie są zmieniane (jak większość obrazów w Internecie) i kiedy nie chcesz, aby CDN odświeżył pliki od początku (co byłoby bezcelowe). Jeśli chodzi o ostatnio zmodyfikowany / etag, to oczywiście inicjuje żądanie i dialog między klientem a serwerem, tylko po to, aby dowiedzieć się, co już wiemy "tak, nadal można obsługiwać plik buforowany". Twój argument brzmi w zasadzie „1 rok to wieczność w internecie”, co nie służy nic produktywnego. Ustawiłem 10 lat przydatności zdjęć, co po prostu służy lepszemu efektowi końcowemu.

— suncat100

Aha, jest też domyślny rozmiar pamięci podręcznej przeglądarki. Czy jakikolwiek zasób w pamięci podręcznej przetrwa rok w pamięci podręcznej przeglądarki? Nie wiem

— redben

Bardzo mało prawdopodobne. Coś, co dodatkowo udowadnia bezcelowość ustawiania "1 roku", kiedy nie służy to żadnemu innemu celowi niż próba buforowania elementu "na zawsze" lub "tak długo, jak to możliwe" ...

— suncat100

Nie chodzi o buforowanie go przez przeglądarkę. Chodzi o pośrednie serwery proxy, które go buforują, takie jak Akamai i Varnish oraz mobilny serwer proxy Google itp.

— Elijah Lynn