Ответ 1
Это зависит от прокси-сервера и от Vary
отклика-заголовка. В общем случае прокси не кэшируют ответ на запрос с заголовком Cookie
. Однако это не гарантируется.
Когда вы указываете заголовок Cache-Control
с директивой public
, вы просите прокси-серверы делиться кешем между разными клиентами. Это, по-видимому, не ваше намерение, поэтому вам следует указать private
. См.: http://www.mnot.net/cache_docs/#CACHE-CONTROL
Какая разница в кэшировании файлов cookie на прокси-сервере?
Не совсем. Все, что он делает, это сообщить прокси, что он не должен служить из устаревшего кеша. Это не влияет на управление кешем.
Будут ли кэшированные файлы кэшироваться на прокси-сервере при доступе к этим файлам? Или кэширование аналогично статическим файлам?
Для части программного обеспечения уровня HTTP (например, прокси) нет никакой разницы между статическим и динамическим контентом. Куки файлы - это только http-заголовки, которые отправляются с запросом (заголовок Cookie
) или отправляются с ответом (Set-Cookie
заголовки)
Если вы установите cookie в браузере (через Javascript или со стороны сервера, через заголовок Set-Cookie
), браузер отправит файл cookie обратно со всеми последующими запросами в тот же домен. Он делает это, добавляя заголовок Cookie
с запросами.
Edit:
Я хочу, чтобы мои фактические файлы были кэшированы на прокси, но не файлы cookie отдельных пользователей. Как это сделать?
Вам нужно избегать кеширования любого ответа, который:
- Содержит заголовок
Set-Cookie
(поскольку это будет кэшироваться прокси-сервером) - На стороне сервера есть побочный эффект (например, важно, чтобы ваше приложение получало запрос - например, было бы нецелесообразно кэшировать пиксель отслеживания)
- Если содержимое заголовков запросов
Cookie
определяет, что получает рендеринг (например, печать "Добро пожаловать назад, Джон Доу" или другая настройка)
Как именно вы это сделаете, это зависит от вашей базовой технологии. Это ваше приложение, которое знает, является ли заголовок Cookie
значимым для ответа, или ответ может потенциально содержать заголовок Set-Cookie
.
В используемой структуре приложения есть функция для установки заголовков кеширования по истечению срока действия. Если я позвоню этому и в рамках одного и того же запроса получаю файлы cookie, я получу ошибку. Это гарантирует, что я случайно не попрошу прокси кэшировать закрытый контент. Вам нужна аналогичная логика, реализованная в вашем приложении.
В качестве альтернативы вы можете настроить прокси-сервер на уровне края, чтобы сделать то же самое. Это обычно делается, если вы полностью не контролируете приложение.
Если у меня есть файлы с использованием заголовка Cache-Control "max-age = 604800, public", будут ли переданы любые cookie файлы cookie-запросов (Cookie) или куки файлы ответов (Set-Cookie) на другой пользовательский компьютер (начиная с его в кеше)? Или он будет кэшироваться только для этого отдельного пользователя?
Файлы cookie запросов не кэшируются и никуда не передаются. Ответ (Set-Cookie
) кэшируется. Поскольку вы указываете Cache-Control
как общедоступный, он будет использоваться среди всех клиентов. Обратите внимание, что хотя cookie-запрос не кэшируется напрямую, если вы отображаете что-то на странице, которое использует файлы cookie (например, если вы используете cookie для состояния сеанса на стороне сервера, например, для проверки подлинности), вы будете кэшировать персонализированный ответ.
Как насчет того, установлен ли параметр Cache-Control "max-age = 7200, proxy-revalidate"? Еще раз спасибо.
То же самое. proxy-revalidate
информирует все прокси (если они есть), что они могут не обслуживать устаревший кеш. Например. как только пройдет 7200 секунд, кеш следует очистить немедленно. Без этого кеши обычно будут обслуживать устаревший кеш, а затем получать новую копию в фоновом режиме, как только тайм-аут будет достигнут. Или нет - зависит от прокси.