Кэш приложений Chrome не отправляет заголовок «Origin» при кэшировании междоменных ресурсов

У меня есть приложение, которое хочет загружать изображения и управлять ими. Браузер требует, чтобы изображение было либо из того же источника, что и приложение, либо чтобы ответ изображения разрешал доступ к другому источнику. Мои изображения обслуживаются через CDN (AWS S3), и они настроены на предоставление правильных заголовков ответа Access-Control-Allow-Origin при запросе с ожидаемым заголовком Origin:

GET /image.png HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, compress
Host: <aws host url here>
Origin: localhost:5000

HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET, HEAD
Access-Control-Allow-Origin: *
Cache-Control: max-age=315360000, no-transform, public
Content-Length: 3333
Content-Type: image/png
Server: AmazonS3
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method

Это будет работать нормально, за исключением того, что мое приложение также имеет дополнительное требование возможности работать в автономном режиме. Для этого я перечисляю URL-адреса ресурсов CDN в манифесте кеша приложения:

CACHE MANIFEST

CACHE:
http://<host url here>/image.png

Проблема, с которой я сталкиваюсь, заключается в том, что после загрузки ресурсов из кэша приложений я начинаю получать Cross-origin image load denied by Cross-Origin Resource Sharing policy ошибок.

Я читал, что Chrome должен отправлять источник манифеста appcache вместе с запросами на заполнение кеша, но, судя по моим беглым исследованиям в chrome://net-internals, в моем случае этого не происходит.

Вот что я вижу в chrome://net-internals/#events, когда выполняется запрос на заполнение кеша:

HTTP_TRANSACTION_SEND_REQUEST_HEADERS
--> GET /image.png HTTP/1.1
    Host: <aws host url here>
    Connection: keep-alive
    Accept-Encoding: gzip,deflate,sdch
    Accept-Language: en-US,en;q=0.8

HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 200 OK
    Cache-Control: max-age=315360000, no-transform, public
    Accept-Ranges: bytes
    Content-Type: image/png
    Content-Length: 3333
    Server: AmazonS3

Кажется, что Chrome не отправляет запрос с заголовком Origin, что означает, что CDN не знает, как ответить заголовками CORS. В результате (я думаю) Chrome кэширует ванильный ответ без перекрестного доступа и обслуживает его из кеша приложения.

Любые советы или идеи будут очень кстати! Спасибо за чтение.


google-chrome cors cross-domain application-cache html5-appcache
person lettertwo    schedule 01.04.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Вы можете создать новую проблему на crbug.com, и она может привлечь больше внимания. Однако, если я правильно понимаю thread (см. второй абзац риска совместимости), кажется, я читал, что Chrome (и, может быть, Safari?) — единственный браузер, который поддерживает вложенные ресурсы перекрестного происхождения в манифесте кэша приложений. Если вы добавите свой запрос в спецификацию кэша приложений, все браузеры (при условии наличия консенсуса и поддержки) могут поддерживать это в будущем. Улучшение нестандартного поведения (нестандартным способом), вероятно, не лучший вариант, поэтому я бы не стал рассчитывать на то, что Chrome реализует ваш запрос без обновления спецификации. Также обратите внимание, что Application Cache заработал довольно негативную репутацию, и сейчас Google и Mozilla продвигают его Service Worker (реализовано в Chrome 40 и Opera 24 и активно разрабатывается в Firefox).

person PhistucK    schedule 01.04.2014
comment
Спасибо за ответ. Я боялся, что ответ будет «нет ответа»! Я открыл тикет, как вы предложили: code .google.com/p/chromium/issues/ - person lettertwo; 01.04.2014