Різниця між відсутнім кешем та необхідним повторним оновленням

З RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

без кешу

Якщо директива no-cache не вказує ім'я поля, то кеш НЕ МОЖЕ використовувати відповідь для задоволення наступного запиту без успішної повторної перевірки з початковим сервером. Це дозволяє серверу-джерелу запобігати кешування навіть кешами, налаштованими для повернення застарілих відповідей на запити клієнтів.

Таким чином, він спрямовує агентів на повторну перевірку всіх відповідей.

У порівнянні з цим

необхідно повторно підтвердити

Коли в відповіді, отриманій кеш-пам'яткою, присутня директива, необхідна для повторної перевірки, цей КЕШ НЕ МОЖЕ НЕ використовувати запис після того, як він стає розмитим, щоб відповісти на наступний запит, попередньо не підтверджуючи його на початковому сервері

Таким чином, він спрямовує агентів на повторну перевірку несвіжих відповідей.

Зокрема, це стосується того no-cache, як насправді користувацькі агенти емпірично ставляться до цієї директиви?

Який сенс, no-cacheякщо є must-revalidateі max-age?

Дивіться цей коментар:

http://palpapers.plynt.com/isissue/2008Jul/cache-control-attributes/

без кешу

Хоча ця директива звучить так, ніби вона вказує браузеру не кешувати сторінку, є тонка різниця. Відповідно до RFC, директива "без кешу" повідомляє браузеру, що він повинен перезавантажитися з сервером, перш ніж подавати сторінку з кеша. Відновлення - це акуратний прийом, який дозволяє додатку зберігати ширину смуги. Якщо сторінка, яку браузер кешував, не змінилася, сервер просто сигналізує про це, і сторінка відображається з кеша. Отже, браузер (теоретично, принаймні) зберігає сторінку в своєму кеші, але відображає її лише після повторної перевірки з сервером. На практиці IE і Firefox почали розглядати директиву no-cache так, ніби вона вказує браузеру навіть не кешувати сторінку. Ми почали спостерігати за такою поведінкою близько року тому.

Хтось отримав щось більш офіційне з цього приводу?

Оновлення

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

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

І ще щось, що я щойно вважав, без Last-Modified або ETags, браузер може лише знову отримати весь ресурс. Однак, з ETags, я помітив, що Chrome принаймні здається, що він скасовується під час кожного запиту. Це змушує обидві ці директиви суперечити або принаймні погано названі, оскільки вони не можуть належним чином переосмислитись, якщо запит також не містить інших заголовків, які в будь-якому разі спричиняють "завжди перезавантажуватися".

Я просто хочу зробити цю останню точку яснішою. Просто встановивши, must-revalidateале не включаючи ні ETag, ні Last-Modified, агент може отримати лише знову вміст, оскільки він не має нічого надсилати на сервер для порівняння.

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

Таким чином, суть must-revalidateполягає в тому, щоб примусити "кеш-обхід", коли він стає несвіжим, що може статися лише тоді, коли ви встановили життя / вік, таким чином, якщо must-revalidateвстановлено відповідь без віку або інших заголовків, це фактично стає рівнозначним no-cacheтому, що відповідь буде вважатися негайно несвіжою.

- Тож я нарешті позначу відповідь Гілі!

Я вважаю, що це must-revalidateозначає:

Щойно кеш закінчується, відмовтеся повертати користувачеві несвіжі відповіді, навіть якщо вони кажуть, що несвіжі відповіді прийнятні.

Тоді як no-cacheвипливає:

must-revalidate плюс той факт, що відповідь відразу стає несвіжим.

Якщо відповідь кешується протягом 10 секунд, то must-revalidateпочинається через 10 секунд, тоді як це no-cacheозначаєmust-revalidate на через 0 секунд.

Принаймні, це моє тлумачення.

max-age=0, must-revalidateі no-cacheне зовсім однакові. З must-revalidate, якщо сервер не відповідає на запит повторної перевірки, браузер / проксі повинен повертати помилку 504. З no-cache, він би просто показував кешований вміст, який, напевно, віддав перевагу користувачеві (краще мати щось несвіже, ніж взагалі нічого). Ось чому must-revalidateвін призначений лише для критичних операцій.

З інтерпретацією Джефрі Фокса про те no-cache, що я перевірив хром 52.0.2743.116 м, результат показує, що no-cacheтака ж поведінка, як must-revalidateі всі, НЕ використовуватиме локальний кеш, коли сервер недоступний, і всі вони будуть використовувати кеш під час натискання Назад браузера / Кнопка вперед, коли сервер недоступний. Як і вище, я думаю, що max-age=0, must-revalidateце ідентично no-cache, принаймні в реалізації.

Я думаю, що існує різниця між max-age=0, must-revalidateта no-cache:

У must-revalidateвипадку, коли клієнту дозволяється надіслати If-Modified-Sinceзапит і подати відповідь з кешу, якщо 304 Not Modifiedвін повернеться.

У no-cacheвипадку, коли клієнт не повинен кешувати відповідь, тому його не слід використовувати If-Modified-Since.