Почему браузеры не учитывают заголовки кэша для начального запроса страницы?

8

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

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

Это просто поведение браузеров по умолчанию, или я упускаю что-то очевидное? Вот заголовки запроса / ответа от попадания на мою домашнюю страницу из инструментов FireFox dev:

ПРИМЕЧАНИЕ / РЕДАКТИРОВАТЬ : Некоторые люди предположили, что это было связано с тем, что Expiresзаголовок был в прошлом. Однако Cache-Controlпереопределяет что-либо в Expiresсоответствии с описанием в RFC 2616 , раздел 14.9.3. Drupal включает это, чтобы отключить кэширование на старых клиентах HTTP 1.0, которые не поддерживают более продвинутый Varyзаголовок, который необходим Drupal для правильного кэширования.

введите описание изображения здесь

cache

— Брайан
источник

11

В ответе есть заголовок Vary: Cookie, Accept-Encoding . Это в значительной степени означает, что если прокси-сервер (включая ваш браузер) хотел кешировать эту страницу, он должен быть готов к кешированию новой версии для каждого, возможно, измененного файла cookie (или изменений в кодировке принятия). В частности, он должен был бы вести учет файлов cookie в первую очередь, поскольку они были отправлены в запросе в качестве отличительного критерия. Я могу себе представить, что либо браузер отрицает это, если cookie слишком велик (и, следовательно, вряд ли будет повторяться), либо он запрещает его, чтобы избежать утечки информации cookie через содержимое кэша, или просто содержимое cookie изменяется при каждом вызов.

— Хаген фон Айцен
источник

4

Просто собирался ответить на мой собственный вопрос, когда я пришел к такому выводу. У меня есть файлы cookie Google Analytics, один из которых изменяется при каждом запросе страницы, предотвращая кэширование страницы.

— Брайан,

2

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

Примером этого на практике является страница корзины покупок / оформления электронной коммерции. Поскольку страница выглядит по-разному каждый раз, невозможно полностью ее кэшировать. Не зная больше о конкретной странице, трудно понять, требует ли страница, на которую вы ссылаетесь, базы данных.

— JMC
источник

Хотя это правда, это не относится к механизму кэширования страниц в Drupal (он буквально кэширует весь вывод HTML и доставляет его для «анонимного» трафика) и не имеет никакого отношения к моему вопросу. Мой вопрос о том, как браузеры неправильно реагируют на соответствующие заголовки кэша страниц, которые установлены (см. Изображение).

— Брайан,

Я видел это раньше во время отладки, но не могу вспомнить, есть ли веская причина, по которой заголовок вашего ответа показывает Expires: Nov 1978? Или это может быть вашим ответом.

— JMC

1

В коде Drupal комментарий выше этого заголовка гласит: «Прокси-серверы HTTP / 1.0 не поддерживают заголовок Vary, поэтому предотвращайте любое кэширование, отправляя дату Expires в прошлом. Клиенты HTTP / 1.1 игнорируют заголовок Expires, если Cache-Control: указана директива max-age = (см. RFC 2616, раздел 14.9.3). " Дата специально является создателем дня рождения Друпала.

— Брайан,

По-прежнему странно, что срок действия не совпадает, например, « Последняя модификация плюс максимальный возраст»

— Хаген фон Айцен

-1

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

— Теро Килканен
источник

Это не так, когда присутствует Cache-Controlзаголовок. Переопределяет Expiresзаголовок для клиентов HTTP 1.1. См. Ietf.org/rfc/rfc2616.txt , раздел 14.9.3.

— Брайан