Из 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/
не-кэш
Хотя эта директива звучит так, будто она инструктирует браузер не кешировать страницу, это тонкая разница. Директива "no-cache", согласно RFC, сообщает браузеру, что он должен сервер, прежде чем обслуживать страницу из кеша. Переопределение - это аккуратный метод, позволяющий приложению сохранять ширину полосы. Если страница, которую кешированный браузер не изменился, сервер просто сигнализирует что в браузере и странице отображается из кеша. Следовательно, браузер (теоретически, по крайней мере) хранит страницу в кеше, но отображает его только после повторной проверки с сервером. На практике IE и Firefox начали рассматривать директиву no-cache, как будто это инструктирует браузер не кэшировать страницу. Мы начали наблюдать это поведение около года назад. Мы подозреваем, что это изменение было вызванное широко распространенным (и неправильным) использованием этой директивы для предотвратить кеширование.
У кого-нибудь есть что-то более официальное в этом вопросе?
Update
Директива must-revalidate должна использоваться серверами тогда и только тогда, когда отказ в проверке запроса в представлении может привести к неправильной работе, такой как незавершенная финансовая транзакция без изменений.
Это то, что я до сих пор не принимал к сердцу. RFC заявляет, что не следует использовать обязательную переоценку. Дело в том, что с помощью веб-сервисов вы должны принять отрицательный взгляд и принять худшее для своих неизвестных клиентских приложений. Любой устаревший ресурс может вызвать проблемы.
И что-то еще, что я только что рассмотрел, без Last-Modified или ETags, браузер может снова извлечь весь ресурс. Однако с помощью ETags я заметил, что Chrome по крайней мере, похоже, проверяет каждый запрос. Это делает обе эти директивы спорными или, по крайней мере, плохо названными, так как они не могут должным образом повторить проверку, если в запрос не включены другие заголовки, которые затем приводят к тому, что они всегда будут всегда проверяться.
Я просто хочу сделать эту последнюю точку более ясной. Просто установив must-revalidate, но не включая ETag или Last-Modified, агент может получить контент снова, так как ему нечего посылать на сервер для сравнения.
Тем не менее, мое эмпирическое тестирование показало, что когда ETAG или измененные данные заголовка включены в ответы, агенты всегда повторяются в любом случае независимо от наличия заголовка must-revalidate.
Таким образом, точка must-revalidate заключается в том, чтобы принудительно "обходить кеш", когда она устарела, что может произойти только тогда, когда вы установили время жизни/возраст, таким образом, если must-revalidate задан в ответе без возраста или другие заголовки, он фактически становится эквивалентным no-cache, так как ответ будет считаться сразу же устаревшим.
- Итак, я собираюсь наконец отметить ответ Гили!
