Почему Firefox игнорирует заголовки кэша и выполняет повторную проверку при refre sh?

Question

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

Вот пример одного из этих ресурсов в Chrome. Как видите, я включаю cache-control: public, max-age, expires, etag и last-modified, а ресурс обслуживается из «кэша памяти»:

---

Firefox, однако, не учитывает эти заголовки и повторно проверяет ресурсы при каждой загрузке! Мой сервер получает запрос на каждый профиль pi c каждый раз при загрузке страницы и возвращает 304:

Вот пример по такому запросу, который приводит к 304:

Я не могу понять, почему Firefox игнорирует заголовки кэша и продолжает идти на сервер для 304. Я экспериментировал с различными заголовками, связанными с кэшем, и прочитал стандарт о том, что «кешируется» . Я гарантировал, что кэширование включено в devtools. Я пытался и с закрытыми devtools, и я постоянно вижу 304 в журналах сервера.

Я обнаружил, что это происходит только на странице refre sh. Простой refre sh, однако, не команда shift или shift, а просто простой refre sh. Это не то поведение, которого я ожидал.

Answer 1

Проще говоря: Firefox повторная проверка кэшированного содержимого в браузере refre sh.

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

Chrome и Firefox, похоже, используют разные способы решения этой проблемы , Подход Chrome заключается в том, чтобы сделать его поведение refre sh более интеллектуальным и изощренным, в то время как Firefox решил положиться на разработчика, явно указав, что не устарелый ресурс никогда не нуждается в повторной проверке с помощью * 1006. * заголовок ответа. (Подробнее об этом различии см. этот ответ ).

Если это поведение refre sh является важным вариантом использования для вашего приложения (в отличие от того, что вы используете для отладки) цели) добавление Cache-Control: immutable должно решить эту проблему в Firefox.

Answer 2

Просто чтобы быть более многословным, позвольте мне остановиться на ETags. Технически, Firefox обрабатывает это правильно. Когда присутствует Etag, клиентские или промежуточные кэши должны выполнить GET или HEAD, чтобы гарантировать, что обслуживаемый контент не изменился.

Заголовок If-None-Match сообщает серверу, какая версия или версии у него есть. , Если он не изменился, сервер / прокси-сервер возвращает 304.

Вы можете изменить поведение повторной проверки, сделав его слабым ETag. Это делается путем включения W / перед значением ETags, то есть ETag: /W #########. Это может быть выполнено на вашем сервере или если вы не можете управлять им с помощью правил перезаписи на вашем CDN.

Возможный обходной путь для Firefox - добавление опций Cache-Control Immutable. Кэш-контроль: неизменяемый . Не смотря на код в Firefox кэширующей эвристике, я не могу сказать наверняка, но это должно быть легко проверить.

Другие серверы будут игнорировать заголовок, если они его не поддерживают.

Etags также не работают с запросами в диапазоне байтов. Поэтому, если у вас нет конкретной c причины для их использования, рассмотрите возможность их отключения.