Почему атрибут Cache-Control отправляется в заголовке запроса (клиент-сервер)?

165

Прочитав о Cache-Controlполе заголовка HTTP,

Я понимаю , что Cache-Controlполе в заголовке ответа HTTP (сервер к клиенту) определяет директивы для промежуточных прокси - сервер / клиентского браузера о том , как обрабатывать ответ, отправив разные значения для Cache-Controlполя: private, public, no-cache, или no-storeв заголовке ответа.

Но я не понимаю, зачем нам отправлять Cache-Controlатрибут в заголовок запроса (клиент-сервер)?

http http-headers

— Ученик
источник

Ответы:

138

Cache-Control: no-cacheобычно используется в заголовке запроса (отправляемом из веб-браузера на сервер) для принудительной проверки ресурса в промежуточных прокси. Если клиент не отправляет этот запрос на сервер, промежуточные прокси-серверы возвращают копию содержимого, если оно свежее (не истекло в соответствии с полями Expireили max-age). Cache-Controlнаправляет эти прокси-серверы для повторной проверки копии, даже если она свежая.

— Дэвид
источник

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

— Сэм

Почему современные браузеры склонны делать это? Они не доверяют промежуточным прокси, даже если ведут себя в соответствии с веб-стандартами ??

— rogerdpack

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

— Джон Ханна

@rogerdpack, если вы только что сделали что-то, что, как вы знаете, изменит состояние и захотят отразить это, будет классическим случаем.

— Джон Ханна

@JonHanna Возможно, в инструментах разработчика Chrome проверено «отключить кэш»? : D

— Григорий Магаршак

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

— bdash
источник

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

Таким образом, чтобы всегда получать ответ от сервера, мы включаем контроль кэша в заголовки запроса. Это гарантирует, что ответ всегда от сервера.

— Loui
источник

Вы говорите: «Таким образом, чтобы всегда получать ответ от сервера, мы включаем контроль кэша в заголовки запроса. Это гарантирует, что ответ всегда будет от сервера». Какое значение этого заголовка будет достигать этого?

— Дон Хэтч

Cache-Control: no-cacheскажет прокси, чтобы убедиться, что ответ полностью проверен.

— Могши