Почему в HTTP-ответе следует использовать как no-cache, так и no-store?
https://stackoverflow.com/questions/866822
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мне сказали, чтобы предотвратить утечку пользовательской информации, одного ответа «без кэша» недостаточно.«Нет магазина» также необходим.
Cache-Control: no-cache, no-store
После прочтения этой спецификации http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, я до сих пор не совсем понимаю, почему.
Насколько я понимаю, это только для сервера промежуточного кэша.Даже если в ответ будет указано «нет кэша», сервер промежуточного кэша все равно сможет сохранить контент в энергонезависимом хранилище.Сервер промежуточного кэша решит, использовать ли сохраненный контент для следующего запроса.Однако если в ответе указано «no-store», сервер промежуточного кэша не должен хранить содержимое.Так что это безопаснее.
Есть ли еще какая-то причина, по которой нам нужны одновременно «без кэша» и «без хранилища»?
Решение
Я должен это уточнить no-cache не значит не кэшировать.Фактически, это означает «повторную проверку на сервере» перед использованием любого кэшированного ответа, который у вас может быть, на каждый запрос.
must-revalidate, С другой стороны, повторную проверку необходимо проводить только в том случае, если ресурс считается устаревшим.
Если сервер сообщает, что ресурс все еще действителен, тогда кэш может ответить своим представлением, что избавляет сервер от необходимости повторно отправлять весь ресурс.
no-store фактически является полным не кэшировать директива и предназначена для предотвращения хранения представления в любой форме кеша.
Я говорю что угодно, но обратите внимание на это в спецификации HTTP RFC 2616:
Буферы истории МОГУТ хранить такие ответы в рамках своей нормальной работы.
Но это опущено в новой спецификации HTTP RFC 7234, возможно, в попытке сделать no-store сильнее, см.:
Другие советы
При определенных обстоятельствах IE6 все равно будет кэшировать файлы, даже если Cache-Control: no-cache находится в заголовках ответов.
Если директива без CACE не указывает имя полевого имени, то в кэше не должен использовать ответ для удовлетворения последующего запроса без успешной переоценки с исходным сервером.
В моем приложении, если вы посетили страницу с no-cache заголовок, затем вышел из системы и затем снова ударил в браузере, IE6 все равно получит страницу из кеша (без нового/проверочного запроса на сервер).Добавление в no-store заголовок остановил это.Но если вы поверите W3C на слово, на самом деле нет способа контролировать такое поведение:
Буферы истории МОГУТ хранить такие ответы в рамках своей нормальной работы.
Описаны общие различия между историей браузера и обычным HTTP-кешированием. в определенном подразделе спецификации.
нет магазина:
Цель нет магазина Целью директивы является предотвращение непреднамеренного выпуска или сохранения конфиденциальной информации (например, на резервных лентах).Директива 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следует использовать только в том случае, если затруднение взаимодействия с пользователем из-за этих функций, которые не работают должным образом или быстро, перевешивается важностью обеспечения того, чтобы контент не хранился в кеше.
Насколько я понимаю, это только для сервера промежуточного кэша.Даже если в ответ будет указано «нет кэша», сервер промежуточного кэша все равно сможет сохранить контент в энергонезависимом хранилище.
Это неверно.Серверы промежуточного кэша, совместимые с HTTP 1.1, будут подчиняться no-cache и must-revalidate инструкции, гарантируя, что контент не кэшируется.Использование этих инструкций гарантирует, что ответ не будет кэшироваться каким-либо промежуточным кэшем и что все последующие запросы будут отправлены обратно на исходный сервер.
Если сервер промежуточного кэша не поддерживает HTTP 1.1, вам нужно будет использовать Pragma: no-cache и надеяться на лучшее.Обратите внимание: если он не поддерживает HTTP 1.1, то no-store в любом случае не имеет значения.
Если система кэширования правильно реализует отсутствие хранилища, то отсутствие кэша вам не понадобится.Но не все это делают.Кроме того, некоторые браузеры реализуют отсутствие кэширования, как если бы оно было без хранилища.Таким образом, хотя это и не является строго обязательным, вероятно, безопаснее включить оба.
В Chrome функция no-cache используется для перезагрузки страницы при повторном посещении, но она все равно кэшируется, если вы вернетесь в историю (кнопка «Назад»).Чтобы перезагрузить страницу и вернуть историю, используйте no-store.IE требует обязательной повторной проверки для работы во всех случаях.
Поэтому, чтобы избежать ошибок и неверных толкований, я всегда использую
Cache-Control: no-store, no-cache, must-revalidate
если я хочу убедиться, что он перезагружается.
Обратите внимание, что 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 кажется, это самое близкое, что все еще работает.
Первоначально мы использовали режим 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-cache может включать имена некоторых полей;в этом случае ответ может быть показан из кэша, за исключением указанных имен полей, которые должны обслуживаться с сервера.Директива no-store применяется ко всему сообщению и указывает, что кеш не должен хранить какую-либо часть ответа или любой запрос, который его запросил.
Я в полной безопасности с этими директивами?
Нет.Но обычно используйте оба Cache-Control:без кэша, без хранилища и Pragma:no-cache, в дополнение к Expires:0 (или дату по Гринвичу, датированную достаточно задним числом, например эпоху UNIX).Типы контента, отличные от HTML, такие как PDF, документы Word, электронные таблицы Excel и т. д., часто кэшируются, даже если установлены вышеуказанные директивы управления кэшем (хотя это зависит от версии и дополнительного использования must-revalidate, pre-check=0, post-check). =0, max-age=0 и s-maxage=0 на практике иногда могут приводить как минимум к удалению файла при закрытии браузера (в некоторых случаях из-за особенностей браузера и реализаций HTTP).Кроме того, функция «Автозаполнение» позволяет браузеру кэшировать все, что пользователь вводит в поле ввода формы.Чтобы это проверить, тег формы или отдельные теги ввода должны включать атрибут Autocomplete="Off".Однако следует отметить, что этот атрибут нестандартен (хотя он поддерживается основными браузерами), поэтому он нарушит проверку XHTML.
Источник здесь.
