Кешът на приложенията на 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

Страхувам се, че няма отговор. Грешката, към която поставихте връзка, не е разрешена - тя е архивирана, тъй като са изминали няколко години без никакви действия от членовете на проекта. Заявките за кеш на приложения с кръстосано начало не включват заглавката Origin.

Можете да създадете нов проблем на crbug.com и той може да привлече повече внимание. Освен ако не разбирам погрешно rel="nofollow">нишка (вижте втория абзац за риска от съвместимост), мисля, че прочетох, че Chrome (и може би Safari?) е единственият браузър, който поддържа подресурси с кръстосан произход в рамките на манифест на кеша на приложения. Ако добавите заявката си в спецификацията на кеша на приложението, всички браузъри (ако приемем, че има консенсус и поддръжка) може да поддържат това в бъдеще. Подобряването на нестандартно поведение (по нестандартен начин) вероятно не е правилният начин, така че не бих разчитал Chrome да изпълни заявката ви без актуализация на спецификацията. Също така имайте предвид, че кешът на приложенията си спечели доста негативна репутация и начинът, по който Google и Mozilla настояват сега, е Service Worker (внедрено в Chrome 40 и Opera 24 и в процес на активна разработка във Firefox).

person PhistucK    schedule 01.04.2014
comment
Благодаря, че се отзовахте. Страхувах се, че отговорът ще бъде „няма отговор“! Отворих билет, както предложихте: код .google.com/p/chromium/issues/ - person lettertwo; 01.04.2014