Как предотвратить запрос, который возвращает 304

Когда браузер НЕ делает запрос на сервер для файла?

Другими словами, у меня есть файл JavaScript. Его заголовок HTTP-ответа имеет ETag , Cache-Control: public и Expires: Tue, 19 Jan 2038 03:14:07 GMT .

Сервер возвращает 304 после того, как кеш браузера был загрунтован.

Мой вопрос: почему браузер даже проверяет сервер и получает 304 в первую очередь? Я не хочу, чтобы браузер спрашивал, есть ли новая версия – он должен загружаться непосредственно из кеша браузера, не проверяя изменения с сервером, обслуживающим скрипт.

Какая комбинация заголовков HTTP-ответов выполняет это?

Во-первых, соответствующей спецификацией HTTP является RFC 7234 . Если вы посмотрите на спецификацию, вы увидите две вещи:

Спецификация никогда ни при каких обстоятельствах не требует , чтобы кеш хранит кешированную версию контента без повторной проверки. Существует множество мест, где спецификация отмечает, что кэш НЕ ДОЛЖЕН использовать кешированный контент для удовлетворения запроса, но ни один из них не указывает, что он ДОЛЖЕН сделать это, или что он НЕ ДОЛЖЕН повторить проверку. Поэтому поставщики браузеров всегда могут переоценить, если захотят.
Во-вторых, вы не делаете ничего плохого на своем конце. Браузеры могут кэшировать ответы и использовать эти кешированные ответы, учитывая заголовки, которые вы возвращаете. Ключевым моментом является раздел 4 , в котором отмечается, что одним из условий для обслуживания кэшированного ответа является то, что ответ является либо:
- свежий (см. раздел 4.2), или
- (см. раздел 4.2.4), или
- успешно подтвержден (см. раздел 4.3).
Поскольку вы выплевываете заголовок Expires который далек в будущем, и этот момент в будущем еще не достигнут, ответ «свежий», и поэтому повторная аттестация не требуется. Таким образом, вы делаете все, что спецификация предлагает вам быть на вашем месте. (Хотя использование Cache-Control: max-age=foo – это более современный способ установки времени истечения кеша, чем использование заголовка Expires: .)

Поэтому, если вы хотите изменить поведение кэширования браузеров, вам не повезло.

Однако все может быть не так плохо, как вы думаете. Вероятно, вы только видите запрос и 304, потому что обновляете страницу в своем браузере при тестировании. Браузеры обрабатывают кэшированные ресурсы по-разному в зависимости от того, как был вызван запрос для них.

Я проверил простой тест, в котором я создал HTML-страницу, содержащую указывающий на JS-файл, указывающий на изображение, и указывающий на таблицу стилей CSS. Все эти файлы были размещены на сервере Apache, настроенном для обслуживания:

заголовок E-Tag,
Дата последней модификации,
Cache-Control: max-age=172800 header

Естественно, что все ресурсы были загружены с использованием 200 кодов при загрузке первой страницы. После этого тестирование в Chrome или Firefox устанавливается с настройками по умолчанию, я заметил, что:

Если вы обновите страницу с помощью клавиши F5 или кнопки « Обновить» , страница и все ресурсы будут revalidate (т. Е. Запрос делается на сервер для каждого ресурса и возвращается 304).
Если вы вернетесь на страницу по ссылке или введите URL-адрес в строку URL-адреса новой вкладки, то повторная проверка не производится (т. Е. Никаких запросов не производится).
В Chrome, если вы обновляете страницу, выбирая строку URL и нажимая «Ввод», сама страница обновляется, но никаких других ресурсов не происходит. В Firefox ни страница, ни ресурсы не проверяются.

На этой странице показано, что Internet Explorer имеет такое же поведение:

Существует ряд ситуаций, в которых Internet Explorer должен проверить, действительна ли кэшированная запись:

Кэшированная запись не имеет даты истечения срока действия и доступ к контенту в первый раз в сеансе браузера

Кэшированная запись имеет срок действия, но срок ее действия истек.

Пользователь запросил обновление страницы, нажав кнопку «Обновить» или нажав F5

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

Google и Mozilla имеют некоторую документацию о кешировании HTTP (я не могу найти что-либо эквивалентное на MSDN или сайте Apple Developers), но также не указывает на наличие каких-либо специфических для конкретного производителя заголовков кеширования, которые могут использоваться для изменения правил, используемых браузером выбрать, когда нужно повторить проверку. То, что вы хотите сделать, просто невозможно.

Если вам действительно нужно больше контролировать это поведение, вы можете посмотреть в кэш приложений HTML5 или перевернуть свою собственную логику кэширования, используя локальное хранилище HTML5, например, файл basket.js .

Expires: или Cache-Control: max-age= должен работать. Вы подтвердили в журналах сервера, что браузер фактически выполняет сетевые вызовы? Я обнаружил, что firebug, например, запутывает вывод, который предполагает, что вы делаете удаленные вызовы, когда вы на самом деле нажимаете на кеш.

Если вы находитесь в моей лодке и имеете приложение «Угловое», развернутое в IIS, убедитесь, что ваш web.config настроен правильно переписать URL-адрес следующим образом: