Из 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
поскольку ответ будет считаться сразу устаревшим.
- Итак, я собираюсь, наконец, отметить ответ Гили!