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

Question

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

Cache-Control: no-cache, no-store

После прочтения этой спецификации http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, Я все еще не совсем уверен, почему.

В настоящее время я понимаю, что это только для промежуточного сервера кеша. Даже если в ответе нет кэша, сервер промежуточного кэша может сохранять содержимое в энергонезависимой памяти. Промежуточный сервер кеша примет решение, использовать ли сохраненный контент для следующего запроса. Однако, если в ответе «нет хранилища», промежуточный сервер кэша не должен хранить контент. Так что это безопаснее.

Есть ли какая-то другая причина, по которой нам нужны "no-cache" и "no-store"?

Answer 1

Я должен уточнить, что no-cache не означает не кэшировать . Фактически это означает «повторную проверку с сервером» перед использованием любого кэшированного ответа, который вы можете иметь, на каждый запрос.

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

Если сервер сообщает, что ресурс все еще действителен, то кэш может ответить своим представлением, что устраняет необходимость повторной отправки сервером всего ресурса.

no-store фактически является полной директивой not cache и предназначена для предотвращения хранения представления в любой форме кеша.

Я говорю что угодно, но учтите это в спецификации RFC 2616 HTTP:

Буферы истории МОГУТ хранить такие ответы как часть их нормальной работы

Но это опущено в более новой спецификации HTTP RFC 7234 в потенциальной попытке сделать no-store сильнее, см .:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

Answer 2

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

W3C состояния no-cache:

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

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

Буферы истории МОГУТ хранить такие ответы как часть их нормальной работы.

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

Answer 3

Из спецификации HTTP 1.1 :

нет-магазин

Цель директивы no-store состоит в том, чтобы предотвратить непреднамеренный выпуск или сохранение конфиденциальной информации (например, на лентах резервных копий). Директива no-store применяется ко всему сообщению и МОЖЕТ быть отправлена ​​либо в ответе, либо в запросе. При отправке в запросе кеш НЕ ДОЛЖЕН хранить какую-либо часть этого запроса или любой ответ на него. При отправке в ответе кэш НЕ ДОЛЖЕН хранить какую-либо часть этого ответа или запроса, который его вызвал. Эта директива применяется как к не совместно используемым, так и совместно используемым кэшам. «НЕ ДОЛЖЕН хранить» в этом контексте означает, что кэш НЕ ДОЛЖЕН преднамеренно хранить информацию в энергонезависимом хранилище и ДОЛЖЕН приложить максимальные усилия для удаления информации из энергозависимого хранилища как можно быстрее после ее пересылки. Даже когда эта директива связана с ответом, пользователи могут явно хранить такой ответ вне системы кэширования (например, с помощью диалога «Сохранить как»). Буферы истории МОГУТ хранить такие ответы как часть их нормальной работы. Цель этой директивы состоит в том, чтобы удовлетворить заявленные требования определенных пользователей и авторов сервисов, которые обеспокоены случайным выпуском информации через непредвиденный доступ к кэш-структурам данных. Хотя использование этой директивы может улучшить конфиденциальность в некоторых случаях, мы предупреждаем, что она никоим образом не является надежным или достаточным механизмом обеспечения конфиденциальности. В частности, злонамеренные или скомпрометированные кэши могут не распознавать или подчиняться этой директиве, а сети связи могут быть уязвимы для прослушивания.

Answer 4

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

• без кеша для IE

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

Обратите внимание, что 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 кажется наиболее близким, что все еще работает.

Answer 9

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

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

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

Answer 10

Просто, что еще хуже, в некоторых ситуациях нельзя использовать no-cache, но no-store может:

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