Какая разница между Cache-Control: max-age = 0 и no-cache?

Ответ 1

У меня был такой же вопрос, и я нашел информацию в моих поисках (ваш вопрос стал одним из результатов). Вот что я определил...

В заголовке Cache-Control есть две стороны. Одна сторона - это то, где он может быть отправлен веб-сервером (он же "исходный сервер" ). Другая сторона - это то место, где он может быть отправлен браузером (он же "пользовательский агент" ).

При отправке сервером происхождения

Я полагаю, что max-age=0 просто сообщает кэшам (и пользовательским агентам), что ответ устарел от get-go, и поэтому они СЛЕДУЕТ повторить проверку ответа (например, с заголовком If-Not-Modified) до используя кешированную копию, тогда как no-cache сообщает им, что они ДОЛЖНЫ повторить проверку перед использованием кешированной копии. Из 14.9.1 Что такое Cacheable:

нет кэша

... кэш НЕ ДОЛЖЕН использовать ответ для удовлетворения последующего запроса без успешной исходный сервер. Это позволяет сервер происхождения, чтобы предотвратить кеширование даже с помощью кэшей, настроенных для возвращать устаревшие ответы клиенту запросы.

Другими словами, кэши иногда могут использовать устаревший ответ (хотя я считаю, что они должны добавить заголовок Warning), но no-cache говорит, что им не разрешено использовать устаревший ответ, независимо от того, что, Возможно, вам понадобится поведение СЛЕДУЕТ -revalidate, когда статистика бейсбола будет сгенерирована на странице, но вы бы хотели, чтобы поведение MUST -revalidate, когда вы сгенерировали ответ к покупке электронной коммерции.

Хотя вы правы в своем комментарии, когда вы говорите, что no-cache не должен предотвращать хранение, на самом деле это может быть еще одна разница при использовании no-cache. Я наткнулся на страницу, Директивы управления кэшем Demystified, в которой говорится (я не могу ручаться за ее правильность):

На практике IE и Firefox имеют начал обработку no-cache директивой, как если бы он инструктировал браузера, чтобы даже не кэшировать страницу. Мы начали наблюдать за этим поведением около года назад. Мы подозреваем, что это изменение было вызвано широко распространенное (и неправильное) использование этого директива для предотвращения кеширования.

...

Обратите внимание, что в последнее время "управление кешем: no-cache" также начал вести себя как директива "no-store".

В стороне, мне кажется, что Cache-Control: max-age=0, must-revalidate должно означать в основном то же самое, что и Cache-Control: no-cache. Возможно, это способ получить ДОЛЖЕН -revalidate поведение no-cache, избегая видимой миграции no-cache, чтобы сделать то же самое, что и no-store (т.е. Никакого кэширования вообще)?

При отправке пользовательским агентом

Я считаю, что ответ shahkalpesh применим к стороне агента пользователя. Вы также можете посмотреть 13.2.6 Disambiguating Multiple Responses.

Если пользовательский агент отправляет запрос с Cache-Control: max-age=0 (aka. "сквозной повторной аттестацией" ), каждый кеш по пути будет revalidate его записи в кэш (например, с заголовком If-Not-Modified) все путь к исходному серверу. Если ответ затем 304 (не изменен), можно использовать кешированный объект.

С другой стороны, отправка запроса с помощью Cache-Control: no-cache (aka. "сквозная перезагрузка" ) не переоценивается, а сервер НЕ ДОЛЖЕН использовать кешированную копию при ответе.

Ответ 2

макс возраста = 0

Это эквивалентно нажатию Refresh, что означает, что дайте мне последнюю копию, если у меня уже есть последняя копия.

no-cache

Это удерживает Shift, нажимая Refresh, что означает, просто переделайте все, что бы ни было.

Ответ 3

Старый вопрос сейчас, но если кто-то еще сталкивается с этим путем поиска, как и я, похоже, что IE9 будет использовать это для настройки поведения ресурсов при использовании кнопок "Назад" и "Вперед". Когда используется max-age = 0, браузер будет использовать последнюю версию при просмотре ресурса при нажатии на кнопку "Назад/Вперед". Если не используется кеш-память, ресурс будет переназначен.

Более подробную информацию о кешировании IE9 можно найти в этом сообщении msgd для кэширования.

Ответ 4

В моих недавних тестах с IE8 и Firefox 3.5 кажется, что оба являются RFC-совместимыми. Однако они отличаются своим "дружелюбием" с исходным сервером. IE8 рассматривает ответы no-cache с той же семантикой, что и max-age=0,must-revalidate. Тем не менее Firefox 3.5, похоже, относится к no-cache как к эквиваленту no-store, что приводит к снижению производительности и использования полосы пропускания.

Squid Cache по умолчанию никогда не хранит ничего с заголовком no-cache, как Firefox.

Моим советом было бы установить public,max-age=0 для нечувствительных ресурсов, которые вы хотите проверять на свежесть при каждом запросе, но все же позволяете использовать кеширование производительности и пропускной способности. Для позиций пользователя с одинаковым учетом используйте private,max-age=0.

Я бы полностью избегал использования no-cache, поскольку, по-видимому, он был унаследован некоторыми браузерами и популярными кэшами к функциональному эквиваленту no-store.

Кроме того, не эмулируйте Akamai и Limelight. Хотя они, по сути, используют массивы кэширования в качестве основного бизнеса и должны быть экспертами, они фактически заинтересованы в том, чтобы больше данных загружалось из их сетей. Google не может быть хорошим выбором для эмуляции. Кажется, они используют max-age=0 или no-cache случайным образом в зависимости от ресурса.

Ответ 5

max-age
    When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate 
its own cache entry, and the client has supplied its own validator in the request, the 
supplied validator might differ from the validator currently stored with the cache entry. 
In this case, the cache MAY use either validator in making its own request without 
affecting semantic transparency. 

    However, the choice of validator might affect performance. The best approach is for the 
intermediate cache to use its own validator when making its request. If the server replies 
with 304 (Not Modified), then the cache can return its now validated copy to the client 
with a 200 (OK) response. If the server replies with a new entity and cache validator, 
however, the intermediate cache can compare the returned validator with the one provided in 
the client request, using the strong comparison function. If the client validator is 
equal to the origin server's, then the intermediate cache simply returns 304 (Not 
Modified). Otherwise, it returns the new entity with a 200 (OK) response. 

    If a request includes the no-cache directive, it SHOULD NOT include min-fresh, 
max-stale, or max-age. 

любезность: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Не принимайте это как ответ - мне нужно будет прочитать его, чтобы понять его истинное использование:)

Ответ 6

Я вряд ли специалист по кешированию, но Марк Ноттингем. Вот его кеширующие документы. Он также имеет отличные ссылки в разделе "Ссылки".

Основываясь на моем чтении этих документов, похоже, что max-age=0 может позволить кешу отправлять кешированный ответ на запросы, которые приходили в "то же самое время", где "то же самое время" означает достаточно близко друг к другу, они выглядят одновременно кеш, но no-cache не будет.

Ответ 7

Кстати, стоит отметить, что некоторые мобильные устройства, в частности продукты Apple, такие как iPhone/iPad, полностью игнорируют заголовки, такие как no-cache, no-store, Expires: 0 или что-то еще, что вы можете попытаться заставить их не повторять -use истекли страницы формы.

Это не вызвало у нас никаких головных болей, поскольку мы пытаемся решить проблему с iPad, говоря о том, что спали на странице, которую они достигли через процесс формы, скажем, шаг 2 из 3, а затем устройство полностью игнорирует директивы store/cache, и, насколько я могу судить, просто берет то, что является виртуальным снимком страницы из его последнего состояния, то есть игнорирует то, что было сказано явно, и не только это, взяв страницу, которая должна не сохраняться и хранить его, не проверяя его снова, что приводит, среди прочего, к различным типам проблем сессии.

Я просто добавляю это, если кто-то приходит и не может понять, почему у них возникают ошибки в сеансе с особенностями iphones и ipads, которые, по-видимому, на самом деле являются худшими нарушителями в этой области.

Я провел довольно обширное тестирование отладчика с этой проблемой, и это мой вывод, устройства полностью игнорируют эти директивы.

Даже при регулярном использовании я обнаружил, что некоторые мобильные телефоны также полностью не могут проверять новые версии, скажем, Expires: 0, а затем проверять последние измененные даты, чтобы определить, должен ли он получить новый.

Просто этого не происходит, поэтому мне пришлось добавить строки запроса к файлам css/js, которые мне нужны для принудительного обновления, что заставляет глупые мобильные устройства думать, что это файл, которого у него нет, например: my.css? v = 1, затем v = 2 для обновления css/js. Это в значительной степени работает.

Пользовательские браузеры также, кстати, если оставить их по умолчанию, с 2016 года, поскольку я постоянно обнаруживаю (мы делаем много изменений и обновлений на нашем сайте), также не удается проверить последние измененные даты в таких файлах, но метод строки запроса исправляет эту проблему. Это то, что я заметил с клиентами и офисными людьми, которые, как правило, используют стандартные стандартные пользовательские настройки по умолчанию в своих браузерах и не знают о проблемах кеширования с помощью css/js и т.д., Почти всегда не могут получить новые css/js при изменении, что означает, что значения по умолчанию для их браузеров, в основном MSIE/Firefox, не выполняют то, что им говорят, они игнорируют изменения и игнорируют последние измененные даты и не проверяют, даже с истечением срока действия: 0 явно.

Это была хорошая тема с большой технической информацией, но также важно отметить, насколько плохая поддержка этого материала в особенно мобильных устройствах. Каждые несколько месяцев я должен добавить больше уровней защиты от их отказа следовать командам заголовка, которые они получают, или правильно интерпретировать эти команды.

Ответ 8

Здесь небольшое дерево решений, которое, я надеюсь, прояснит разницу.

Ответ 9

Cache-Control: max-age = 0 и без кэширования

Вы можете узнать все по ссылке выше.

Cache-control

Ответ 10

Я пишу серию статей, в которых подробно рассматриваются эти темы, которые ИМХО явно недостаточно обсуждаются среди разработчиков.

Браузеры, частные прокси и CDN:
https://medium.com/free-code-camp/http-caching-in-depth-part-1-a853c6af99db

Cache-Control & Vary https://medium.com/@lojacquemin/an-in-depth-introduction-to-http-caching-cache-control-vary-e3229815ddf4

Ответ 11

Отличие заключается в том, что no-cache (no-store on Firefox) предотвращает любое кэширование. Это может быть полезно для предотвращения записи страниц с защищенным контентом на диск и для страниц, которые всегда должны обновляться, даже если они повторно посещаются с помощью кнопки "Назад".

max-age = 0 указывает, что запись в кэше устарела и требует повторной проверки, но не предотвращает кеширование. Часто браузеры проверяют ресурсы только один раз за сеанс браузера, поэтому контент может не обновляться до тех пор, пока сайт не будет посещен в новом сеансе.

Обычно браузеры не будут удалять истекшие записи кэша, если только они не возвращают пространство для более нового содержимого, когда кеш браузера заполнен. Использование no-store, no-cache позволяет явно удалять запись в кеш.