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

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

вопрос задан 26.06.2009
rubyruy
3056 репутация

9 ответов


  • 524 рейтинг

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

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


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

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

    без кеша

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

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

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

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

    . , ,

    Обратите внимание, что в последнее время "контроль кеша: no-cache "тоже начал себя вести как директива «без магазина».

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


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

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

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

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

    ответ дан Michael Krebs, с репутацией 6282, 5.09.2009
  • 37 рейтинг

    max-age = 0

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

    без кеша

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

    ответ дан Cheng, с репутацией 686, 12.05.2015
  • 30 рейтинг

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

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

    ответ дан El Yobo, с репутацией 11643, 27.11.2010
  • 23 рейтинг

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

    ответ дан rmalayter, с репутацией 427, 25.01.2010
  • 19 рейтинг
    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. орг / Протоколы / RFC2616 / RFC2616-Sec14. HTML # Sec14. 9. 4

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

    ответ дан shahkalpesh, с репутацией 28888, 26.06.2009
  • 11 рейтинг

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

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

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

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

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

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

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

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

    ответ дан Lizardx, с репутацией 901, 13.04.2016
  • 11 рейтинг

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

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

    ответ дан Hank Gay, с репутацией 50912, 26.06.2009
  • 10 рейтинг

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

    Cache-control decision tree diagram

    ответ дан pravdomil, с репутацией 1725, 19.04.2018
  • 0 рейтинг

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

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

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

    ответ дан HttpWatchSupport, с репутацией 2646, 26.06.2009