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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

не-магазин

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

Ответ 4

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

• no-cache для IE

• no-store для Firefox

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

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

Ответ 5

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

Как это устроено:

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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

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