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



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

129   9  

9 ответов:

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

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


при отправке исходным сервером

я считаю max-age=0 просто говорит кэши (и агенты пользователей) ответ черствый с самого начала, и поэтому они должны повторная проверка ответа (например. с помощью ) перед использованием кэшированной копии, тогда как, no-cache говорит им, что они должны повторите проверку перед использованием кэшированной копии. От 14.9.1 что такое Cacheable:

no-cache

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

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

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

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

...

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

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


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

я считаю shahkalpesh это относится к стороне агента пользователя. Вы также можете посмотреть 13.2.6 Устранение Неоднозначности Множественных Ответов.

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

С другой стороны, отправка запроса с Cache-Control: no-cache (ака. "end-to-end reload") не переоценивает и сервер должны Не использовать кэшированную копию при ответе.

max-age=0

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

no-cache

Это удерживая Shift при нажатии кнопки Обновить, что означает, просто повторите все, несмотря ни на что.

старый вопрос сейчас, но если кто-то еще столкнется с этим через поиск, как я сделал, похоже, что 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
    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's request, using the strong comparison function. If the client's 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

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

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

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

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

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

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

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

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

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

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

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

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

Cache-control decision tree diagram

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

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

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

    Ничего не найдено.

Добавить ответ:
Отменить.