Разница между отсутствием кэша и обязательной повторной проверкой


179

Из RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

нет кэша

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

Таким образом, он направляет агентов для повторной проверки всех ответов.

По сравнению с этим

обязательно перепроверить

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

Таким образом, он направляет агентов на повторную проверку устаревших ответов.

Особенно это касается того no-cache, как пользовательские агенты действительно эмпирически относятся к этой директиве?

Какой смысл, no-cacheесли есть must-revalidateи max-age?

Смотрите этот комментарий:

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

нет кэша

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

У кого-нибудь есть что-нибудь более официальное по этому поводу?

Обновить

Директива must-revalidate должна использоваться серверами тогда и только тогда, когда неудачная проверка запроса на представление может привести к некорректной работе, такой как молчаливая неисполненная финансовая транзакция.

Это то, что я никогда не принимал близко к сердцу до сих пор. RFC говорит, что не следует использовать легкую переаттестацию. Дело в том, что с веб-сервисами вы должны принять негативное мнение и предположить худшее для ваших неизвестных клиентских приложений. Любой устаревший ресурс может вызвать проблему.

И что-то еще, что я только что рассмотрел, без Last-Modified или ETag, браузер может только получить весь ресурс снова. Однако, с ETag, я заметил, что Chrome, по крайней мере, кажется, повторяется при каждом запросе. Что делает обе эти директивы спорными или, по крайней мере, плохо названными, так как они не могут должным образом выполнить повторную проверку, если запрос также не включает другие заголовки, которые затем вызывают «всегда повторную проверку» в любом случае.

Я просто хочу прояснить этот последний момент. Просто устанавливая, must-revalidateно не включая ETag или Last-Modified, агент может только получить контент снова, так как ему нечего отправить на сервер для сравнения.

Однако мое эмпирическое тестирование показало, что когда ETag или измененные данные заголовка включены в ответы, агенты всегда проходят повторную проверку в любом случае, независимо от наличия must-revalidateзаголовка.

Таким образом, смысл must-revalidateсостоит в том, чтобы принудительно использовать «обходной кэш», когда он устареет, что может произойти, только если вы установили время жизни / возраст, поэтому, если must-revalidateзадан ответ без возраста или других заголовков, он фактически становится эквивалентным, no-cacheпоскольку ответ будет считаться сразу устаревшим.

- Итак, я собираюсь, наконец, отметить ответ Гили!


Таким образом , в теории разница Validate-всегда против валидации-если-несвежей , в то время как на практике нет кэш не получает лечение некоторых браузеров , как комментарий вы процитировали говорит , как никогда Validate ... так что вы должны сделать свой выбор, какой из них для использования основываясь на том, какое поведение кеширования вы на самом деле хотите достичь на практике ...
CBroe

Пожалуйста, прочитайте greenbytes.de/tech/webdav/… и посмотрите, что это прояснит для вас.
Джулиан Решке


проверьте это дерево решений для ответа stackoverflow.com/a/49925190/3748498
pravdomil

Ответы:


191

Я считаю, что это must-revalidateозначает:

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

Принимая во внимание, что no-cacheподразумевает:

must-revalidate плюс тот факт, что ответ сразу становится устаревшим.

Если ответ кэшируется в течение 10 секунд, то срабатывает must-revalidateчерез 10 секунд, а no-cacheподразумевается must-revalidateчерез 0 секунд.

По крайней мере, это моя интерпретация.


2
Вот как я это вижу сейчас. Интересная часть - мой последний параграф, без ETag или Last-Modified, агенту нечего использовать для проверки того, что он имеет в кэше, и он должен снова загрузить всю полезную нагрузку. Так что, когда RFC говорит «revalidate», это, вероятно, означает «повторный выбор».
Люк Пуплетт

44
Что также означает max-age=0, must-revalidateи no-cacheидентичны
Anshul

5
@Anshul, сначала я думал, что вы были правы, что 'max-age = 0, must-revalidate и no-cache одинаковы', но посмотрите ответ Джеффри Фокса, который, кажется, указывает, что это не совсем правильно.
Дон Хэтч

2
@Anshul Нет, must-revalidateи no-cacheимеют разное значение для свежих ответов: если кэшированный ответ является новым (т. Е. Срок действия ответа не истек), must-revalidateпрокси-сервер сразу же отправит его без повторной проверки на сервере, тогда no-cacheкак прокси-сервер должен повторно подтвердить кэшированный ответ независимо от свежести. Источник: «HTTP - Полное руководство», стр. 182-183.
Матиас Браун

8
@MatthiasBraun А, я вижу источник путаницы. Может быть, я должен был написать no-cacheи max-age=0, must-revalidateидентичны
Anshul

24

max-age=0, must-revalidateи no-cacheне совсем идентичны. С must-revalidate, если сервер не отвечает на запрос перепроверки, браузер / прокси должен возвращать ошибку 504. При этом no-cacheон будет просто показывать кэшированный контент, который, вероятно, будет предпочтительным для пользователя (лучше иметь что-то устаревшее, чем вообще ничего). Именно поэтому must-revalidateпредназначен только для критических транзакций.


10
Не уверен насчет вашей no-cacheинтерпретации. Из RFC 7234 директива ответа «без кэширования» указывает, что ответ НЕ ДОЛЖЕН использоваться для удовлетворения последующего запроса без успешной проверки на исходном сервере. Это позволяет исходному серверу предотвратить использование его кэшем для удовлетворения запроса, не связываясь с ним, даже с помощью кэшей, которые были настроены для отправки устаревших ответов. Это звучит похоже на ограничения дляmust-revalidate
Anshul

9
Есть ли у Джеффри доказательства того, что реализации ведут себя так, как он описал?
OrangeDog

Я думаю, что этот ответ правильный для прокси-серверов. Но в действительности браузеры не возвращают 504 в этом случае.
Янн Динендал

Так must-validateзначитmust-refresh
Simon_Weaver

15

С интерпретацией Джеффри Фокса о том no-cache, что я тестировал в chrome 52.0.2743.116 m, результат показывает, что он no-cacheработает так же, как must-revalidateи все они НЕ будут использовать локальный кеш, когда сервер недоступен, и все они будут использовать кеш, когда нажмите «Назад» браузера. Кнопка / Вперед, когда сервер недоступен. Как и выше, я думаю, что max-age=0, must-revalidateидентично no-cache, по крайней мере, в реализации.


Будет ли Chrome использовать локальный кеш, когда сервер будет доступен для повторной проверки? (т. е. «если модифицирован-с»). В обоих случаях?
Богатый

-2

Я думаю, что есть разница между max-age=0, must-revalidateи no-cache:

В must-revalidateслучае, если клиенту разрешено отправлять If-Modified-Sinceзапрос и обслуживать ответ из кеша, если 304 Not Modifiedон возвращается.

В этом no-cacheслучае клиент не должен кэшировать ответ, поэтому не следует использовать If-Modified-Since.


6
Но no-cacheэто не значит , no-store- с no-cache, ресурс еще можно кэшировать в клиенте; это просто должно быть повторно проверено перед использованием?
Арон

4
Вы смешиваете no-cacheи no-store. no-cacheозначает, что ресурс ДОЛЖЕН быть переоценен . Revalidate включает возможность использовать условные запросы, такие как If-None-Matchи If-Modified-Since.
Жюль Сэм. Рэндольф

1
@JulesRandolph: вы можете быть правы. Есть ли у вас какие-либо тесты / демоверсии? Все противоречивые утверждения без доказательств по этому вопросу разочаровывают. Даже принятый ответ просто говорит: «По крайней мере, это моя интерпретация». Я мог бы установить испытательный стенд и опубликовать его здесь, если у меня будет время.
Богатый
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.