Подтвердить что ты не робот

Chrome игнорирует Control-Cache: max-age?

Фон:

  • IIS 7
  • Веб-приложение AspNet 3.5

Инструменты Chrome dev содержат 98 запросов для домашней страницы веб-приложения (aspx + js + css + images). В следующих запросах код состояния 200 для файлов css/images. Нет информации о кеше, браузер запрашивает сервер каждый раз, если файл должен быть обновлен. OK.

В IIS 7 я устанавливаю HTTP-заголовок для управления кешем, установленный в 6 часов для папки "ressources". В Chrome, используя инструменты dev, я вижу, что заголовок хорошо установлен в ответ:

Cache-Control: max-age=21600

Но я все еще получаю 98 запросов... Я думал, что браузер не должен запрашивать один ressource, если его дата истечения не достигнута, и я ожидал, что количество запросов будет уменьшено...

4b9b3361

Ответ 1

Я понял. Google Chrome игнорирует заголовок Cache-Control или Expires, если вы делаете запрос сразу после другого запроса на тот же URI на той же вкладке (нажав кнопку обновления, нажав клавишу F5 или нажав Command + R). Вероятно, у него есть алгоритм, чтобы угадать, что действительно хочет сделать пользователь.

Способ тестирования заголовка Cache-Control - это возврат документа HTML со ссылкой на него. При нажатии на ссылку Chrome отправляет документ из кеша. Например, назовите следующий документ self.html:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Test Page</title>
</head>
<body>
    <p>
        <a href="self.html">Link to the same page.</a>
        If correctly cached, a request should not be made
        when clicking the link.
    </p>
</body>
</html>

Другой вариант - скопировать URL-адрес и вставить его на ту же вкладку или на другую вкладку.

ОБНОВЛЕНИЕ. На странице Опубликованная Chrome 26 января 2017 года описано, что было предыдущим поведением и как это изменяется, делая только повторную проверку основного ресурса, но не под-ресурсов:

Пользователи обычно перезагружаются либо потому, что страница сломана, либо содержимое кажется устаревшим. Существующее поведение перезагрузки обычно решает сломанные страницы, но устаревшее содержимое неэффективно устраняется путем регулярной перезагрузки, особенно на мобильных устройствах. Эта функция была первоначально разработана в моменты, когда сломанные страницы были довольно распространены, поэтому было разумно сразу обращаться к обоим вариантам использования. Однако эта первоначальная проблема теперь стала гораздо менее актуальной, поскольку качество веб-страниц увеличилось. Чтобы улучшить испорченный контент, Chrome теперь имеет упрощенное поведение перезагрузки, чтобы проверить только основной ресурс и продолжить регулярную загрузку страницы. Это новое поведение максимизирует повторное использование кэшированных ресурсов и приводит к более низкой задержке, потреблению энергии и использованию данных.

В сообщении Facebook, опубликованном 26 января 2017 года, упоминается, что они нашли фрагмент кода, были лишены хеширования всех кэшированных ресурсов после запроса POST:

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

Кажется, что это уже не так.

Наконец, описано, что Firefox вводит Cache-Control: immutable, чтобы полностью остановить повторную проверку ресурсов:

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

Я надеюсь, что это поможет распутать тайны перезагрузки.

Ответ 2

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

В качестве примера у меня было это приложение Ruby Sinatra:

#!/usr/bin/env ruby

require 'sinatra'

before do
  content_type :txt
end

get '/' do
  headers "Cache-Control" => "public, must-revalidate, max-age=3600",
          "Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s
  "This page rendered at #{Time.now}."
end

Когда я постоянно перезагружаю его на той же вкладке Chrome, он отображает новое время.

This page rendered at 2014-10-08 13:36:46 -0400.
This page rendered at 2014-10-08 13:36:48 -0400.

Заголовки выглядели следующим образом:

< HTTP/1.1 200 OK
< Content-Type: text/plain;charset=utf-8
< Cache-Control: public, must-revalidate, max-age=3600
< Expires: 2014-10-08 13:36:46 -0400
< Content-Length: 48
< X-Content-Type-Options: nosniff
< Connection: keep-alive
* Server thin is not blacklisted
< Server: thin

Однако при доступе к одному и тому же URL http://localhost:4567/ из нескольких новых вкладок будет перерабатывать предыдущий результат из кэша.

Ответ 3

После нескольких тестов с Cache-Control:max-age=xxx:

  • Нажатие кнопки перезагрузки: заголовок игнорируется
  • Ввод одного и того же URL-адреса любой вкладки (текущий или нет): honored
  • Использование JS (window.location.reload()): игнорируется
  • Использование инструментов разработчика (с отключенным кешем не выбрано) или инкогнито не влияет на

Итак, лучший вариант при разработке поместите курсор в омнибокс и нажмите клавишу вместо кнопки обновления.

Примечание. При нажатии правой кнопки мыши на значке обновления отображаются параметры обновления (обычный, жесткий, пустой кэш). Невероятно, ни один из них не влияет на эти заголовки.

Ответ 4

Если Chrome Developer Tools открыты (F12), Chrome обычно отключает кеширование.

Он управляется в настройках инструментов разработчика - значок Gear справа от верхней панели dev-tools.

Ответ 5

Другой совет:

Не забудьте проверить заголовок "Дата" - если у сервера неверная дата/время (или находится в другом часовом поясе) - Chrome будет продолжать запрашивать ресурс снова и снова.