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

Заголовок Cache-Control: max-age=0подразумевает, что контент считается устаревшим (и должен быть повторно извлечен) немедленно, что фактически означает то же самое, что и Cache-Control: no-cache.

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

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

Когда отправлено сервером происхождения

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

нет кэша

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

Другими словами, кеши могут иногда использовать устаревший ответ (хотя я полагаю, что они должны добавить Warningзаголовок), но no-cacheговорят, что им нельзя использовать устаревший ответ, несмотря ни на что. Может быть , вы хотите РЕКОМЕНДУЕМЫЙ -revalidate поведения , когда статистика бейсбол генерируется на странице, но вы хотите MUST -revalidate поведения , когда вы сгенерировали ответ на покупку электронной коммерции.

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

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

...

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

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

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

Я считаю, что ответ Шахкалпеша относится к агенту пользователя. Вы также можете посмотреть на 13.2.6 Устранение неоднозначности множественных ответов .

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

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

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

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

нет кэша

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

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

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

В моих недавних тестах с 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случайном порядке в зависимости от ресурса.

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

    Однако выбор валидатора может повлиять на производительность. Лучший подход для
промежуточный кеш для использования собственного валидатора при выполнении запроса. Если сервер отвечает
с 304 (не изменено), тогда кеш может вернуть свою теперь проверенную копию клиенту 
с ответом 200 (ОК). Если сервер отвечает с новым объектом и валидатором кэша,
однако промежуточный кэш может сравнивать возвращенный валидатор с тем, который указан в 
запрос клиента, используя функцию сильного сравнения. Если валидатор клиента
равный серверу источника, то промежуточный кеш просто возвращает 304 (не 
Modified). В противном случае он возвращает новый объект с ответом 200 (ОК).

    Если запрос включает в себя директиву no-cache, он НЕ ДОЛЖЕН включать min-fresh, 
max-stale или max-age. 

вежливость: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

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

Я не эксперт по кешированию, но Марк Ноттингем. Вот его кеширующие документы . У него также есть отличные ссылки в разделе «Рекомендации».

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

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

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

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

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

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

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

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

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

Одна вещь, которая (что удивительно) не было упомянуто, - то, что запрос может явно указать, что он примет устаревшие данные, используя max-staleдирективу. В этом случае, если сервер max-age=0ответит, кеш просто рассмотрит устаревший ответ и будет свободен использовать его для удовлетворения запроса клиента [который запрашивал потенциально устаревшие данные]. Напротив, если сервер отправляет, no-cacheэто действительно превосходит любой запрос клиента (с max-stale) для устаревших данных, так как кэш ДОЛЖЕН повторно проверить.

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

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

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