Почему в ответе HTTP должны использоваться как no-cache, так и no-store?

при определенных обстоятельствах IE6 все равно будет кэшировать файлы, даже если Cache-Control: no-cache в заголовки ответа.

на W3C в Штаты no-cache:

если директива no-cache не Укажите имя поля, затем кэш Не следует использовать ответ для удовлетворения последующий запрос без успеха revalidation с исходным сервером.

в моем приложении, если вы посетили страницу с помощью тега no-cache заголовок, затем вышел из системы, а затем вернулся в браузер, IE6 все равно захватит страницу из кэша (без нового/проверяющего запроса на сервер). Добавление в no-store заголовок остановил это. Но если вы возьмете W3C на слово, на самом деле нет никакого способа контролировать это поведение:

буферы истории могут хранить такие ответы как часть их нормальной работы.

общие различия между историей браузера и обычным кэшированием HTTP описал в определенном подразделе спецификации.

с спецификация HTTP 1.1:

нет-магазине:

цель нет-магазине директива предназначена для предотвращения непреднамеренного выпуска или хранения конфиденциальной информации (например, на резервных лентах). Директива no-store применяется ко всему сообщению и может быть отправлена либо в ответ, либо в запросе. При отправке запроса кэш не должен хранить какую-либо часть этого запроса или ответа к нему. При отправке ответа кэш не должен хранить ни часть этого ответа, ни запрос, который его вызвал. Эта директива применяется как к общим, так и к общим кэшам. "Не должен хранить" в этом контексте означает, что кэш не должен намеренно хранить информацию в энергонезависимом хранилище и должен приложить все усилия, чтобы удалить информацию из энергонезависимого хранилища как можно быстрее после ее пересылки. Даже если эта директива связана с ответом, пользователи может явно хранить такой ответ вне системы кэширования (например, с диалоговым окном "Сохранить как"). Буферы истории могут хранить такие ответы как часть их нормальной работы. Цель этой директивы-удовлетворить заявленные требования определенных пользователей и авторов услуг, которые обеспокоены случайными выпусками информации через непредвиденные доступы к структурам данных кэша. Хотя использование этой директивы может улучшить конфиденциальность в некоторых случаях, мы предупреждаем, что это не так способ надежный или достаточный механизм обеспечения конфиденциальности. В частности, вредоносные или скомпрометированные кэши могут не распознавать или не подчиняться этой директиве, а коммуникационные сети могут быть уязвимы для подслушивания.

Если вы хотите предотвратить все кэширование (например, обновить при использовании кнопки "Назад") необходимо:

• нет-кэш для IE

• нет-магазин для Firefox

вот моя информация об этом здесь:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

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

Как работает:

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

• использование no-store предотвратит это, но это может повлиять на способность браузера давать "источник просмотра"," назад"," информацию о странице " и так далее без создания нового запрос на сервер, что нежелательно. Другими словами, пользователь может попробовать просмотреть источник, и если браузер не сохранил его в памяти, им либо скажут, что это невозможно, либо это вызовет новый запрос на сервер. Поэтому no-store следует использовать только в том случае, если затрудненный пользовательский интерфейс этих функций не работает должным образом или быстро перевешивается важностью обеспечения того, чтобы содержимое не хранилось в кэше.

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

Это неверно. Промежуточные серверы кэша, которые следуют спецификации HTTP 1.1, будут подчиняться инструкции no-cache и must-revalidate (или proxy-revalidate), гарантируя, что содержимое не кэшируется. Использование этих двух инструкций гарантирует, что ответ не кэшируется никакими промежуточный кэш, и что все последующие запросы отправляются обратно на исходный сервер

Если промежуточный сервер кэша не поддерживает HTTP 1.1, то вам нужно будет использовать Pragma: no-cache и надеяться на лучшее. Обратите внимание, что если он не поддерживает HTTP 1.1, то no-store не имеет значения.

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

обратите внимание, что Internet Explorer от версии 5 до 8 выдаст ошибку при попытке загрузить файл, обслуживаемый через https и сервер отправки Cache-Control: no-cache или Pragma: no-cache заголовки.

см.http://support.microsoft.com/kb/812935/en-us

использование Cache-Control: no-store и Pragma: private кажется, самая близкая вещь, которая все еще работает.

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

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

Cache-Control: no-store, no-cache, must-revalidate

если я хочу убедиться, что он перезагружается.

Первоначально мы использовали no-cache много лет назад и столкнулись с некоторыми проблемами с устаревшим контентом в некоторых браузерах... К сожалению, не помню подробностей.

с тех пор мы остановились только на использовании no-store. Никогда не оглядывались назад или не имели ни одной проблемы с устаревшим контентом любым браузером или посредниками с тех пор.

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

чтобы сделать вещи еще хуже, в некоторых ситуациях нет-кэш не может быть использован, но нет-store может:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/