Почему этот запрос GET не кэшируется браузером? - PullRequest
Новая
       31

Почему этот запрос GET не кэшируется браузером?

0 голосов
/ 22 июня 2019

В моем приложении у меня есть запрос GET для получения изображений от конечной точки API.

Это заголовки, возвращаемые сервером для изображения.

Access-Control-Allow-Origin: http://localhost:3001

Cache-Control: public, max-age = 43200

Соединение: keep-alive

Контент-расположение: вложение;имя_файла = blah.jpg

Длина содержимого: 567829

Тип содержимого: image / jpg

Дата: сб, 22 июня 2019 17:05:18 GMT

ETag: "1560511770.8223343-567829-3517588627"

Срок действия истекает: Sun, 23 июня 2019 05:05:18 GMT

Последнее изменение: пт, 14 июня 2019 11:29: 30 GMT

Сервер: gunicorn / 19.7.1

Strict-Transport-Security: max-age = 31536000;includeSubDomains

Варьируется: Происхождение

Некоторая другая полезная информация:

  1. Конечная точка GET защищена аутентификацией на основе jwt.В этом случае я ожидал бы, что он не будет кэшироваться по умолчанию, но поскольку сервер явно предоставляет Cache-Control: public, я бы подумал, что это должно быть кэшировано сейчас.

  2. Конечная точка API имеетдругой домен от домена приложения пользовательского интерфейса.Я пробовал его на другом сервере, на котором я мог вносить изменения, и запросы, находящиеся в разных источниках, не имели значения для кэширования.

  3. Запрос изображения не отправляется из браузера, онотправляется из приложения, как и любой другой запрос GET.Это сделано потому, что конечная точка находится за аутентификацией.Это также означает, что это изображение выбирается с помощью responseType: "blob", после чего создается URL-адрес большого двоичного объекта и устанавливается как image src.Если бы URL-адрес большого двоичного объекта каждый раз отличался (что я вижу), это привело бы к неиспользованию кэшированной версии ресурса?Я ожидаю, что содержимое кэша разрешается еще до создания URL-адреса большого двоичного объекта, поэтому это не должно иметь значения.

  4. Может ли размер ответа быть фактором?Я бы так не думал.

  5. Приложение пользовательского интерфейса работает по протоколу http, а конечная точка API - по протоколу https.Может ли это быть проблемой?

  6. Заголовок Vary: Origin не должен запрещать кэширование, так как я делаю запросы из того же источника

Iожидал, что этот ответ будет кэшироваться в течение 43200 секунд, независимо от аутентификации пользователя, но он даже не кэшируется для одного и того же пользователя с тем же токеном (каждый раз, когда я нажимаю на кнопку, чтобы получить его снова, я не вижу ничегона вкладке Chrome Network указывается, что он извлекается из кеша диска или памяти)

В чем может быть причина того, что этот ответ вообще не кэшируется?

РЕДАКТИРОВАТЬ:

При дальнейшем запросе кажется, что виновником может быть заголовок Content-Disposition: attachment, как уже упоминалось здесь , он плохо работает с кэшированием Chrome.Ресурс кэшируется и обслуживается из кэша в Firefox.Я все еще ищу решение для Chrome, поэтому вопрос открыт.

РЕДАКТИРОВАТЬ: даже после изменения Content-Disposition на inline, Chrome не кеширует его: /

...