Чому в HTTP-відповіді слід використовувати і кеш-пам'ять, і не-магазин?

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

Cache-Control: no-cache, no-store

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

Моє теперішнє розуміння полягає в тому, що це лише для проміжного кеш-сервера. Навіть якщо відповідь "без кешу" відповідає, сервер проміжного кешу все ще може зберегти вміст у енергонезалежне сховище. Проміжний кеш-сервер вирішить, чи використовувати збережений вміст для наступного запиту. Однак якщо у відповіді є "no-store", проміжний розділ кешу не повинен зберігати вміст. Отже, безпечніше.

Чи є якась інша причина, яка нам потрібна і "без кешу", і "немає магазину"?

Треба уточнити, що no-cacheне означає не кешувати . Насправді це означає "перезавантажитись із сервером" перед тим, як використовувати будь-яку кешовану відповідь, на кожен запит.

must-revalidateз іншого боку, потребує переоцінки лише тоді, коли ресурс вважається застарілим.

Якщо сервер каже, що ресурс все ще дійсний, кеш може відповісти своїм представленням, тим самим полегшуючи потребу сервера повторно відправити весь ресурс.

no-storeфактично є повною директивою не кешувати і покликана запобігати збереженню представлення в будь-якій формі кешу.

Я кажу що б там не було, але зауважте це у специфікації HTC 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 :

немає магазину :

Призначення не-магазинуДиректива полягає у запобіганні ненавмисного вивільнення або збереження чутливої ​​інформації (наприклад, на резервних стрічках). Директива про магазин не стосується всього повідомлення, і МОЖЕ бути надіслана або у відповіді, або у запиті. Якщо він надсилається в запиті, КЕШ НЕ МОЖЕТЕ зберігати будь-яку частину цього запиту або будь-якої відповіді на нього. Якщо надіслано у відповідь, кеш НЕ МОЖЕТЕ зберігати будь-яку частину цього відповіді або запиту, який його викликав. Ця директива поширюється на кеші, що не поділяються, та спільні. "НЕ МАЄТЕ зберігати" в цьому контексті означає, що кеш НЕ МОЖЕ навмисно зберігати інформацію в енергонезалежному сховищі, і ОБОВ'ЯЗКОВО докладати максимум зусиль, щоб видалити інформацію з енергонезалежного сховища якомога швидше після її пересилання. Навіть коли ця директива пов'язана з відповіддю, користувачі можуть явно зберігати таку відповідь поза системою кешування (наприклад, у діалоговому вікні "Зберегти як"). Буфери історії МОЖУТЬ зберігати такі відповіді як частину їх нормальної роботи. Метою цієї директиви є задоволення заявлених вимог певних користувачів та авторів сервісів, які стурбовані випадковим вивільненням інформації через непередбачуваний доступ до кеш-структур даних. Хоча використання цієї директиви в деяких випадках може покращити конфіденційність, ми застерігаємо, що це НЕ в жодному разі не є надійним або достатнім механізмом забезпечення конфіденційності. Зокрема, зловмисні або порушені кеші можуть не визнавати та не підкорятися цій директиві, а комунікаційні мережі можуть бути вразливими для підслуховування. Буфери історії МОЖУТЬ зберігати такі відповіді як частину їх нормальної роботи. Метою цієї директиви є задоволення заявлених вимог певних користувачів та авторів сервісів, які стурбовані випадковим вивільненням інформації через непередбачуваний доступ до кеш-структур даних. Хоча використання цієї директиви в деяких випадках може покращити конфіденційність, ми застерігаємо, що це НЕ в жодному разі не є надійним або достатнім механізмом забезпечення конфіденційності. Зокрема, зловмисні або порушені кеші можуть не визнавати та не підкорятися цій директиві, а комунікаційні мережі можуть бути вразливими для підслуховування. Буфери історії МОЖУТЬ зберігати такі відповіді як частину їх нормальної роботи. Метою цієї директиви є задоволення заявлених вимог певних користувачів та авторів сервісів, які стурбовані випадковим вивільненням інформації через непередбачуваний доступ до кеш-структур даних. Хоча використання цієї директиви в деяких випадках може покращити конфіденційність, ми застерігаємо, що це НЕ в жодному разі не є надійним або достатнім механізмом забезпечення конфіденційності. Зокрема, зловмисні або порушені кеші можуть не визнавати та не підкорятися цій директиві, а комунікаційні мережі можуть бути вразливими для підслуховування. Хоча використання цієї директиви в деяких випадках може покращити конфіденційність, ми застерігаємо, що це НЕ в жодному разі не є надійним або достатнім механізмом забезпечення конфіденційності. Зокрема, зловмисні або порушені кеші можуть не визнавати та не підкорятися цій директиві, а комунікаційні мережі можуть бути вразливими для підслуховування. Хоча використання цієї директиви в деяких випадках може покращити конфіденційність, ми застерігаємо, що це НЕ в жодному разі не є надійним або достатнім механізмом забезпечення конфіденційності. Зокрема, зловмисні або порушені кеші можуть не визнавати та не підкорятися цій директиві, а комунікаційні мережі можуть бути вразливими для підслуховування.

Якщо ви хочете запобігти всі кешування (наприклад, змусити перезавантажити при використанні кнопки "назад"), вам потрібно:

• відсутність кешу для IE

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

Тут є моя інформація про це:

http://blog.httpwatch.com/2008/10/15/two-important-differences-bet 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це все одно не має значення.

Якщо система кешування правильно реалізовує no-store, то вам не знадобиться no-кеш. Але не всі так роблять. Крім того, деякі веб-переглядачі реалізовують кеш-пам'ять, як це не було. Таким чином, хоча це не суворо вимагається, включити обидва.

Зауважте, що 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-store. Щоб працювати в будь-яких випадках, IE потрібно перекваліфікувати.

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

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

якщо я хочу переконатися, що він перезавантажується.

Спочатку ми використовували без кеш-пам'яті багато років тому і зіткнулися з деякими проблемами з несвіжим вмістом у певних браузерах ... На жаль, не пам'ятаю конкретику.

З тих пір ми влаштувались НАДІЛЬНО на використання магазину. З тих пір ніколи не оглядався або не мав жодної проблеми із несвіжим вмістом жодним браузером чи посередниками.

Цей простір, безумовно, переважає реальність реалізацій порівняно з тим, що трапляється написано в різних RFC. Багато довірених осіб, як правило, вважають, що вони роблять кращу роботу з «поліпшення результативності», замінюючи політику, яку вони повинні дотримуватися, своєю.

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

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

OWASP обговорює це:

Яка різниця між директивами кешування кеша: no-cache та no-store?

Директива no-cache у відповіді вказує на те, що відповідь не повинна використовуватися для подачі наступного запиту, тобто кеш не повинен відображати відповідь, у якій зазначена ця директива встановлена ​​в заголовку, але повинен дозволяти серверу обслуговувати запит. Директива без кешу може включати деякі назви полів; у такому випадку відповідь може бути показана з кеша, за винятком вказаних імен полів, які слід подавати з сервера. Директива про недоторканність поширюється на все повідомлення і вказує, що кеш не повинен зберігати жодну частину відповіді або будь-який запит, який її запитував.

Я цілком безпечний з цими директивами?

Ні. Але, як правило, використовуйте як кеш-контроль: без кешу, ні-магазину, так і прагми: не-кеш-пам'ять, крім терміну дії: 0 (або достатньо задніх дат GMT, таких як епоха UNIX). Типи вмісту, що не є html, як pdf, текстові документи, таблиці Excel та ін., Часто отримують кешування, навіть коли встановлені вищезазначені директиви управління кешем (хоча це залежить від версії та додаткового використання must-revalidate, pre-check = 0, post-check = 0, max-age = 0, а на практиці s-maxage = 0 іноді може призвести до принаймні видалення файлу після закриття браузера в деяких випадках через хитрощі браузера та реалізацію HTTP). Також функція "Автозаповнення" дозволяє браузеру кешувати всі типи користувачів у полі введення форми. Щоб перевірити це, тег форми або окремі теги введення повинні містити атрибут "Автозаповнення =" Вимкнено ". Однак,

Джерело тут .