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

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

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

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


http http-headers
person Student    schedule 26.01.2013    source источник

Ответы (3)


arrow_upward
147
arrow_downward

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

person David    schedule 27.01.2013
comment
Может быть, уже слишком поздно, но, кроме этого, для чего еще? Используется ли поле max-age для каких-либо целей? - person Sam; 01.01.2016
comment
Почему современные браузеры склонны делать это? Они не доверяют промежуточным прокси, хотя ведут себя в соответствии с веб-стандартами ?? - person rogerdpack; 17.02.2017
comment
@rogerdpack нет, потому что они действительно доверяют им, поэтому они отправляют заголовок, которому они доверяют, будут иметь честь указать, что у них есть особая причина требовать большей свежести, чем в большинстве случаев необходимость. - person Jon Hanna; 14.03.2017
comment
@JonHanna, но в чем их особая причина? Кажется, что большинство браузеров отправляют это, по сути, когда-либо запрашивая что-то, чего они не кэшировали? - person rogerdpack; 14.03.2017
comment
@rogerdpack, если вы только что сделали что-то, что, как вы знаете, изменило состояние, и хотите это отразить, будет классическим случаем. - person Jon Hanna; 15.03.2017
comment
@JonHanna Возможно, вы отключили кеш, проверенный в инструментах разработчика Chrome? : D - person Gregory Magarshak; 06.12.2017
comment
Я работаю над CRM, где пользователь находится в исправлении, затем выполняется GET для получения полностью обновленного профиля, который ... Я знаю, что он должен просто использовать ответ PATCH, но по причинам. В любом случае, когда GET вызывается впоследствии, если мы не использовали Cache-Control: no-cache, тогда только что сделанные изменения не будут отражены. Все остальные запросы уважают кеш, но сразу после изменения вы хотите его обновить. - person Phil Sturgeon; 10.01.2018
comment
@david Мой браузер отправляет Cache-Control: max-age = 0 в заголовке запроса. Что это значит. Означает ли это, что браузер всегда будет получать свежую копию независимо от того, что предыдущий заголовок ответа содержит некоторое положительное значение максимального возраста? - person Aniket; 22.06.2018
comment
@Sam Поздно в игре, но в разделе 14.9 HTTP RFC указано, где могут использоваться директивы кэша запросов и ответов: - Сервер источника может указывать, что кэшируется - Сервер источника или пользовательский агент могут указывать, что может храниться в кеше - То же самое для модификаций основного механизма истечения срока действия - Только пользовательский агент контролирует повторную валидацию кеша и перезагрузить - Оба? может управлять преобразованием сущностей. - Оба? может расширить систему кеширования. - person spygi; 25.09.2018
comment
Этот ответ также может помочь: stackoverflow.com/a/42653090/5763764 - person Radek Matěj; 09.01.2019
comment
Скажем, сервер не выполняет никакого кэширования, но клиент хотел бы сделать это для повышения производительности. Может ли клиент запросить у браузера кэширование HTTP-вызова, даже если сервер ничего не делает с этим? - person azizj; 20.03.2020

arrow_upward
15
arrow_downward

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

person bdash    schedule 26.01.2013

arrow_upward
5
arrow_downward

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

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

person Loui    schedule 18.06.2014
comment
Вы говорите «Таким образом», чтобы всегда получать ответ от сервера, мы включаем управление кешем в заголовки запросов. Это гарантирует, что ответ всегда будет с сервера. Какое значение этого заголовка позволит это сделать? - person Don Hatch; 30.06.2016
comment
Cache-Control: no-cache сообщит прокси, чтобы убедиться, что ответ подтвержден полностью. - person mogsie; 08.03.2017