В чем разница между Cache-Control: max-age=0 и no-cache?
Заголовок Cache-Control: max-age=0 подразумевает, что контент считается устаревшим (и должен быть повторно извлечен) немедленно, что фактически означает то же самое, что и Cache-Control: no-cache,
11 ответов
У меня был тот же вопрос, и я нашел некоторую информацию в моих поисках (ваш вопрос появился как один из результатов). Вот что я определил...
Есть две стороны Cache-Control заголовок. С одной стороны, это может быть отправлено веб-сервером (он же "сервер происхождения"). С другой стороны, он может быть отправлен браузером (он же "пользовательский агент").
Когда отправлено сервером происхождения
я верю max-age=0 просто сообщает кешам (и пользовательским агентам), что ответ устарел с самого начала, и поэтому они ДОЛЖНЫ повторно проверить ответ (например, с помощью If-Not-Modified header) перед использованием кэшированной копии, тогда как, 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, Так что, возможно, это способ получить ОБЯЗАТЕЛЬНОЕ поведение no-cache, избегая при этом очевидной миграции no-cache делать то же самое, что и no-store (т.е. без кеширования вообще)?
Когда отправлено агентом пользователя
Я считаю, что ответ Шахкалпеша относится к агенту пользователя. Вы также можете посмотреть на 13.2.6 Устранение неоднозначности множественных ответов.
Если пользовательский агент отправляет запрос с Cache-Control: max-age=0 (так называемый "сквозной повторной проверки"), то каждый кэш по пути будет повторной проверки своей записи в кэше (например, с If-Not-Modified заголовок) вплоть до исходного сервера. Если ответ равен 304 (не изменен), можно использовать кэшированный объект.
С другой стороны, отправка запроса с Cache-Control: no-cache (он же "сквозная перезагрузка") не проходит повторную проверку, и сервер НЕ ДОЛЖЕН использовать кэшированную копию при ответе.
макс возраста =0
Это эквивалентно нажатию кнопки " Обновить", что означает, что вы получите самую последнюю копию, если у меня уже нет последней копии.
нет кэша
Это удерживает Shift при нажатии Refresh, что означает, просто переделывать все, что бы ни случилось.
Старый вопрос сейчас, но если кто-то еще столкнется с этим через поиск, как я, кажется, что IE9 будет использовать это для настройки поведения ресурсов при использовании кнопок "назад" и "вперед". Когда используется max-age=0, браузер будет использовать последнюю версию при просмотре ресурса при нажатии на кнопку вперед / назад. Если не использовать кеш, ресурс будет обновлен.
Более подробную информацию о кэшировании 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 Когда промежуточный кеш вынужден с помощью директивы max-age=0 повторно проверять свою собственную запись в кеше, и клиент предоставил в запросе свой собственный валидатор, предоставленный валидатор может отличаться от валидатора, хранящегося в данный момент. с записью в кеш. В этом случае кеш МОЖЕТ использовать любой валидатор при создании собственного запроса, не влияя на семантическую прозрачность. Однако выбор валидатора может повлиять на производительность. Наилучшим подходом для промежуточного кэша является использование собственного валидатора при выполнении запроса. Если сервер отвечает 304 (не изменено), то кэш может вернуть клиенту свою теперь проверенную копию с ответом 200 (ОК). Однако, если сервер отвечает новым объектом и средством проверки кэша, промежуточный кэш может сравнить возвращенный объект проверки с указанным в запросе клиента, используя функцию строгого сравнения. Если валидатор клиента равен серверу источника, то промежуточный кеш просто возвращает 304 (не изменено). В противном случае он возвращает новый объект с ответом 200 (ОК). Если запрос включает директиву no-cache, он НЕ ДОЛЖЕН включать min-fresh, max-stale или max-age.
вежливость: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Не принимайте это как ответ - я должен буду прочитать это, чтобы понять истинное использование этого:)
Я не эксперт по кешированию, но Марк Ноттингем. Вот его кеширующие документы. У него также есть отличные ссылки в разделе "Рекомендации".
Судя по прочтению этих документов, похоже, max-age=0 может позволить кэш-памяти отправлять кэшированный ответ на запросы, поступившие в одно и то же время, где "одно и то же время" означает, что достаточно близко друг к другу они выглядят одновременно с кешем, no-cache не будет.
Кстати, стоит отметить, что некоторые мобильные устройства, в частности продукты Apple, такие как iPhone/iPad, полностью игнорируют заголовки, такие как no-cache, no-store, Expires: 0 или что-то еще, что вы можете попытаться заставить их не использовать повторно. страницы формы.
Это вызвало у нас бесконечную головную боль, поскольку мы пытаемся решить проблему, связанную с IPad пользователя, когда он засыпает на странице, которую он достиг в процессе формы, скажем, шаг 2 из 3, а затем устройство полностью игнорирует магазин / директивы кеша, и, насколько я могу судить, просто извлекают то, что является виртуальным снимком страницы, из ее последнего состояния, то есть игнорируют то, что было сказано явно, и, не только это, извлекают страницу, которая не должна храниться и сохраняя его, фактически не проверяя его снова, что, помимо прочего, приводит к всевозможным странным проблемам Session.
Я просто добавляю это в случае, если кто-то приходит и не может понять, почему он получает ошибки сеанса, особенно с iphone и ipads, которые, похоже, являются худшими нарушителями в этой области.
Я провел довольно обширное тестирование отладчика с этой проблемой, и я пришел к выводу, что устройства полностью игнорируют эти директивы.
Даже при регулярном использовании я обнаружил, что некоторые мобильные телефоны также не могут проверять наличие новых версий, например, Expires: 0, а затем проверяют даты последних изменений, чтобы определить, должна ли она получить новую.
Этого просто не происходит, поэтому я был вынужден добавить строки запроса в файлы css/js, которые мне нужны для принудительного обновления, что заставляет глупые мобильные устройства думать, что это файл, которого у него нет, например: my.css?v=1, затем v=2 для обновления css/js. Это в основном работает.
Браузеры пользователей также, кстати, если оставить их по умолчанию, начиная с 2016 года, как я постоянно обнаруживаю (мы делаем МНОГО изменений и обновлений на нашем сайте), также не в состоянии проверять даты последнего изменения в таких файлах, но запрос Строковый метод исправляет эту проблему. Это то, что я заметил с клиентами и офисными людьми, которые, как правило, используют обычные стандартные пользовательские настройки по умолчанию в своих браузерах и не знают о проблемах кэширования css/js и т. Д., Почти всегда не получая новые css/js при изменении, это означает, что настройки по умолчанию для их браузеров, в основном MSIE / Firefox, не выполняют то, что им велено, они игнорируют изменения и игнорируют даты последнего изменения и не проверяют, даже если Expires: 0 установлен явно.
Это была хорошая ветка с большим количеством технической информации, но также важно отметить, насколько плоха поддержка этого материала, особенно на мобильных устройствах. Каждые несколько месяцев мне приходится добавлять новые уровни защиты от их неспособности следовать командам заголовка, которые они получают, или правильно интерпретировать эти команды.
Вот небольшое дерево решений, которое, я надеюсь, прояснит разницу.
Ответ на этот вопрос содержится непосредственно в документах MDN :
Большинство кешей HTTP/1.0 не поддерживают директивы, поэтому исторически они использовались в качестве обходного пути. Но только
max-age=0может привести к повторному использованию устаревшего ответа при отключении кэшей от исходного сервера.must-revalidateобращается к этому. Вот почему приведенный ниже пример эквивалентен .Cache-Control: max-age=0, must-revalidateНо пока вы можете просто использовать
no-cacheвместо.
Одна вещь, о которой (на удивление) не упоминалось, - это то, что запрос может явно указать, что он будет принимать устаревшие данные, используя max-staleдиректива. В том случае, если сервер ответилmax-age=0, кеш просто посчитает ответ устаревшим и сможет свободно использовать его для удовлетворения запроса клиента [который запрашивает потенциально устаревшие данные]. Напротив, если сервер отправляетno-cache который действительно превосходит любой запрос клиента (с max-stale) для устаревших данных, поскольку кеш ДОЛЖЕН пройти повторную проверку.
Разница в том, что no-cache (no-store на Firefox) предотвращает любое кэширование. Это может быть полезно для предотвращения записи страниц с защищенным содержимым на диск и для страниц, которые всегда должны обновляться, даже если их повторно посещают с помощью кнопки "Назад".
max-age = 0 указывает, что запись в кэше устарела и требует повторной проверки, но не предотвращает кэширование. Зачастую браузеры проверяют ресурсы только один раз за сеанс браузера, поэтому содержимое может не обновляться, пока сайт не будет посещен в новом сеансе.
Обычно браузеры не удаляют записи кэша с истекшим сроком, если только они не освобождают место для нового содержимого, когда кэш браузера заполнен. Используя no-store, no-cache позволяет явно удалить запись в кэше.