Почему в ответе HTTP следует использовать и без кеша, и без хранения?

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

Cache-Control: no-cache, no-store

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

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

Есть ли еще какая-то причина, по которой нам нужны и «без кеширования», и «без хранения»?

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

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

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

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

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

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

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

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

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

W3C заявляет оno-cache :

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

В моем приложении, если вы посетили страницу с 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инструкции, гарантируя , что содержимое не кэшируется. Использование этих инструкций гарантирует, что ответ не кэшируется каким-либо промежуточным кешем, и что все последующие запросы будут отправлены обратно на исходный сервер.

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

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

Обратите внимание, что 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 требует повторной валидации для работы во всех случаях.

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

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

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

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

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

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

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

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

OWASP обсуждает это:

В чем разница между директивами управления кешем: no-cache и no-store?

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

Я в полной безопасности с этими директивами?

Нет. Но, как правило, используйте Cache-Control: no-cache, no-store и Pragma: no-cache, в дополнение к Expires: 0 (или достаточно заднюю дату по Гринвичу, например, эпоху UNIX). Типы содержимого, отличные от HTML, такие как pdf, текстовые документы, электронные таблицы Excel и т. Д., Часто кэшируются, даже если установлены указанные выше директивы управления кешем (хотя это зависит от версии и дополнительного использования must-revalidate, pre-check = 0, post-check = 0, max-age = 0 и s-maxage = 0 на практике иногда может привести как минимум к удалению файла при закрытии браузера в некоторых случаях из-за особенностей браузера и реализаций HTTP). Кроме того, функция «Автозаполнение» позволяет браузеру кэшировать все, что пользователь вводит в поле ввода формы. Чтобы проверить это, тег формы или отдельные теги ввода должны включать атрибут 'Autocomplete = "Off"'. Тем не мение,

Источник здесь .