Кэширование Chrome и Safari 302 redirect

Question

Уже были заданы различные вкусы, но я еще не нашел реального ответа на это.

У нас есть отдельная услуга изображения, которую наше веб-приложение использует для получения некоторых своих изображений. Служба изображений хорошо протестирована и функционирует должным образом. Чтобы сделать это конкретным, наше приложение подано от domain.com. Элемент src элементов img - images.domain.com/{imageId}. Служба изображений извлекает URL-адрес изображения и отправляет обратно HTTP 302 перенаправление для изображения.

Приложение позволяет пользователям изменять изображения. Так скажите, что пользователь 5 имеет изображение A в качестве изображения профиля, и решает его изменить, загрузив изображение B. Когда пользователь загружает изображение, кэш приложения корректно недействителен и база данных обновляется. Приложение не стандартное перенаправление после POST и один из элементов страницы, которые пользователь перенаправляется к после изменения ее образ что-то вроде:

<img src="example.domain.com/5"> 

Проблема в том, что Chrome никогда не делает вызов example.domain.com/5 к извлекать изображение при первоначальном перенаправлении или регулярной перезагрузке страницы, он просто служит изображению A из кеша браузера. Автономный вызов example.domain.com/5 правильно возвращает изображение B, а жесткое обновление или очистка кеша Chrome заставляет Chrome запрашивать src изображения, которое правильно возвращает изображение B. Обратите внимание, что я не говорю об обслуживании изображения из кеша после получения ответа 304 Not Modified, я говорю о том, что Chrome решил не посещать imgsrc и просто возвращать изображение A. Кроме того, добавление некоторой уникальной строки запроса в атрибут imgsrc устраняет проблему, но это хак, который нам не нужно делать.

Стоит отметить, что Firefox сначала делал то же самое. Первоначально в ответе не было заголовков Cache Control. Мы добавили заголовок Cache Control: no-cache (и попробовали no-store) в заголовок ответа, и это зафиксировало поведение в Firefox, но Chrome и Safari по-прежнему обслуживают устаревшее кэшированное изображение без звонка на src изображения.

Похоже, что это была давняя ошибка в Chromium (https://code.google.com/p/chromium/issues/detail?id=103458), которая предположительно установлена ​​примерно 6 недель назад, но мы используем самую последнюю версию Chrome.

Мы рассмотрели ответы here и here, но они фактически не отвечают на вопрос.

Per раздел 14.9.1 of RFC 2616:

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

Если мы не не хватает что-то или делать что-то не так, то, казалось бы, что Chrome (и Safari) не выполняют поведение RFC для no-cache заголовков для 302 переадресовывает? Кто-нибудь испытывает это раньше или имеет какое-либо понимание?

Answer 1

Пожалуйста, прочтите это .. https://www.hochmanconsultants.com/articles/301-versus-302.shtml

Chrome имеет довольно агрессивное кэширование.

Когда вы используете временную переадресацию, вы в основном говорите, что фактический URL-адрес временно недоступен, поэтому вместо этого используйте этот другой URL. Chrome корректно кэширует старый URL-адрес, поскольку он по-прежнему действителен. Попробуйте 301 вместо этого. Затем Chrome должен знать, что исходный URL-адрес больше недействителен.

Answer 2

cache-control: no-store

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

В отчаянии, я наткнулся на this open WebKit bug и увидел роковой комментарий (и, наконец, проблеск надежды):

CachedRawResource теперь хранит в перенаправлении цепи, и имеет некоторую тривиальную логику для проверки правильности, но это далеко не near complete (только проверяет cacheControlContainsNoStore()). И, конечно, у других типов ресурсов ничего нет.

Добавил no-store в мой заголовок cache-control и не стал больше проблем.