Просить Chrome обойти локальный кеш для XmlHttpRequest, как это возможно в Firefox?

Question

Как некоторые из вас, возможно, уже знают, в Firefox / Chrome есть некоторые проблемы с кэшированием запросов, инициируемых объектом XmlHttpRequest.Эти проблемы означают, что браузер не строго следует правилам и не обращается к серверу для нового файла XSLT (например).Ответ не имеет заголовка Expires (по соображениям производительности мы не можем его использовать).

В Firefox есть дополнительный параметр в "канале" объекта XHR, в который вы помещаете значение Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE, чтобы перейти ксервер явно.

Существует ли что-то подобное для Chrome?

Позвольте мне немедленно остановить всех , которые бы рекомендовали добавлять метку времени в качестве значения параметра GET или случайного целого числа - Iне хочу чтобы сервер получал разные URL-запросы.Я хочу получить исходный URL.Причина в том, что я хочу защитить сервер от получения слишком большого количества различных запросов для простых статических файлов и отправки слишком большого количества данных клиентам, когда это не нужно.

Если вы нажмете на статический файл с сгенерированным параметром GET (например, '?forcenew = 12314 ') будет выдавать 200 ответов каждый раз и 304 для каждого последующего запроса для этого значения случайного целого числа.Я хочу делать запросы, которые всегда будут возвращать 304, если целевой статический файл идентичен версии клиента.Кстати, именно так веб-браузеры должны работать «из коробки», но объекты XHR, как правило, вообще не идут на сервер, чтобы спросить, изменился файл или нет.

Answer 1

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

Если у вас есть номер редакции, например, subversion revision или аналогично из git /mer или что вы используете, добавьте это.Статические файлы будут получать 304 ответа до момента выпуска новой ревизии.Когда происходит новый выпуск, предоставляется один ответ 200, и он возвращается к счастливой генерации 304 ответов.: -)

Это дает дополнительный бонус за независимость от браузера.

Если вам не повезло и у вас нет номера ревизии, то создавайте его и увеличивайте его при каждом выпуске.

Answer 2

Вам следует заглянуть в Etags , etags - это ключи, которые могут быть сгенерированы из содержимого файла, поэтому, как только файл на сервере изменится, система станет новым etag. Очевидно, что это будет изменение на стороне службы, которое вам нужно будет сделать, учитывая, что вы хотите 200, а затем последующие 304. Chrome и FF должны уважать эти etags, поэтому вам не нужно делать сумасшедшие хаки на стороне клиента.

Answer 3

Chrome теперь поддерживает HTTP-заголовок Cache-Control: max-age=0 запроса.Вы можете установить его после открытия экземпляра XMLHttpRequest:

xhr.setRequestHeader( "Cache-Control", "max-age=0" );

. Это приведет к тому, что Chrome не будет использовать кэшированный ответ без повторной проверки.

Для получения дополнительной информации проверьте Состояние кэширования браузера, пересмотренное Марком Ноттингемом и Протокол передачи гипертекста RFC 7234 (HTTP / 1.1): Кэширование .