Назад | Перейти на главную страницу

Заголовки кэширования HTTP: как должна работать повторная проверка?

С помощью трассировка, Я получаю ответ со следующим заголовком:

Cache-control: must-revalidate

Более того, заголовок Expires не отправляется. Однако наш локальный прокси-сервер кэширует эти ответы, поэтому при редактировании страницы необходимо «жестко обновить» для обновления. Прокси-сервер плохо себя ведет? Другие заголовки, которые мощь быть актуальным:

Connection          Keep-Alive
Proxy-Connection    Keep-Alive
Keep-Alive          timeout=15, max=100

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

В частности, им разрешено вычислять собственную так называемую эвристическую актуальность для ответов с определенными кодами состояния HTTP (включая 200 OK). Обычно это основано на стоимости Last-Modified заголовок; например, если LM был создан 1 день назад при первом сохранении ответа, кеш может рассчитывать, что он будет свежим в течение 2 часов.

must-revalidate это инструкция, которая сообщает кешам, что если что-то устаревает, это необходимо проверить на исходном сервере. Если его нет, кеши могут (как правило) использовать устаревшие ответы в необычных обстоятельствах (например, если они теряют связь с исходным сервером).

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

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

http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache

что, надеюсь, делает это немного яснее, чем RFC2616.

Также, http://redbot.org/ проверит URL-адреса и объяснит, как кеши обрабатывают определенные директивы ответа.