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

120

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

Cache-Control: no-cache, no-store

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

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

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

Морган Ченг
источник
3
no-cacheне означает то, что вы думаете. На самом деле это означает «пожалуйста, подтвердите».
Erwan Legrand

Ответы:

77

Сразу уточню, что 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

Люк Пуплетт
источник
18
Все еще не отвечаете на вопрос: почему в HTTP-ответе следует использовать и no-cache, и no-store? Не Cache-Control: no-storeдостаточно?
Франклин Ю
Есть ли различия между браузерами? Потому что эта статья от Microsoft docs.microsoft.com/en-us/iis/configuration/system.webServer/… даже не упоминает no-storeи описывает, no-cacheкак будто она вообще не кэширует… Я запутался!
Roel
Ответ Альконжи - это, в частности, ответ на вопрос. Когда я ответил, я сделал это только для того, чтобы прояснить очень распространенное представление. Проголосуйте за другой ответ!
Люк Пуплетт
48

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

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

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

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

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

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

Alconja
источник
7
когда вы открываете браузер, IE6 не захватывает страницу из кеша. Он берет страницу из буфера истории.
Pacerier
1
В Chrome 34 (2014) это no-storeтоже необходимо установить . В противном случае Chrome будет отображать кэшированные / буферизованные данные при использовании кнопки возврата.
caw
4
-1, потому что первое предложение ошибочно подразумевает, что браузеру неправильно кэшировать ответ с no-cacheзаголовком. Приведенная ниже цитата W3C ясно показывает, что это не так; скорее, no-cacheзаголовок просто означает, что ответ должен быть повторно проверен перед повторным использованием для обслуживания последующих запросов.
Марк Эмери
1
Формулировка спецификации была улучшена с RFC1616 до текущей версии спецификации ( семейство RFC tools.ietf.org/html/rfc7230 ). семья, потому что это 6 RFC. Они устарели 2616.
Arcin B
16

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

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

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

backslash17
источник
1
Если вы уже не кэшируете запрос, разве это не предотвратило бы хранение ответа на энергонезависимом носителе?
Lèse Majesté
4
@ Lèsemajesté Чаще всего нет. no-cacheи max-age=0говорят, что элемент считается устаревшим. Это означает, что он должен быть повторно проверен перед обслуживанием. Это означает, что кеш может сохранить файл, а затем выполнить условный запрос, на который сервер может ответить 304 NOT MODIFIED. Очевидно, что это огромное преимущество, так как не нужно создавать и отправлять текст ответа. Итак, чтобы воспользоваться преимуществами этого большого количества (большинства?) Кешей, мы будем хранить no-cacheответы.
Кевин Кокс
14

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

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

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

Вот моя информация об этом:

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

HttpWatchSupport
источник
6
Почему для Internet Explorer не хватит магазина без магазина? Ваше сообщение в блоге не объясняет.
Simon Lieschke 06
1
О какой версии IE вы говорите?
Pacerier
1
@Pacerier, Наверное, какая бы версия IE ни была последней на момент написания комментария. Согласно Википедии, это был IE7. Для FF это выглядит как 3. Немногие люди все еще используют их.
trysis 08
11

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это все равно не имеет значения.

thomasrutter
источник
3
Я что-то неправильно понимаю, потому что mnot.net/cache_docs/#CACHE-CONTROL вам противоречит. В нем говорится, что no-cacheподдерживается жесткая свежесть, не жертвуя всеми преимуществами кеширования, что означает, что кеш сохраняется и используется снова, если сервер отвечает 304 Not Modified.
Pacerier
-1: отсутствие кеширования не означает, что содержимое нельзя кэшировать. В спецификации 14.9.1 What Is Cachable говорится: «Если директива no-cache не указывает имя поля, то кеш НЕ ДОЛЖЕН использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере». ( w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9. ) Как объясняет Крис Шифлетт, это «не мешает системе кэширования хранить кэшированную копию. Оно просто требует, чтобы система кэширования повторно проверила свой кэш перед отправить его обратно клиенту ". (Руководство разработчика HTTP, стр. 91)
james.garriss 03
Я не думаю, что то, что я написал в этом ответе, сокращает любой из этих двух комментариев - я просто не говорил о том, как браузеры проходят повторную валидацию (например, с помощью If-Modified-Since / If-None-Match), потому что я не видел в этом Соответствующий. Я даже не пытался объяснить, для чего нужен no-cache, поэтому мне трудно понять, как комментарий @ james.garriss связан с моим ответом.
thomasrutter
7

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

james.garriss
источник
« Но не все. «Нам нужен конкретный пример, чтобы убедить моего коллегу.
Франклин Ю
Этот комментарий был сделан 6 лет назад. Вам нужно будет изучить текущее поведение кэширующих серверов, чтобы увидеть, что они делают.
james.garriss
6

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

Bassim
источник
2
Как предлагается в соответствующем ответе SO, вы можете установить именно Cache-Control: no-store, no-cache, must-revalidateэтот порядок, чтобы он работал. Однако это не сработало в нашем сценарии, но то, что @bassim предложил выше, сработало. Спасибо!
Eirik H
6

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

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

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

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

woens
источник
2

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

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

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

Эйнштейн
источник
Я считаю, что раньше Firefox предпочитал расширение no-store.
bvdb
-1

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"'. Тем не мение,

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

Ян Ланковский
источник
Это неверно. no-cacheговорит, что вы не можете использовать его без проверки на сервере. Если ваша кешированная копия все еще в порядке, сервер ответит 304, и вы затем используете кешированную копию. Сохраняет потенциально большую загрузку из сети. no-storeс другой стороны, говорит, что вам вообще не разрешено кэшировать данные.
Горгулья