I have an app that wants to load and manipulate images. The browser requires that the image be either from the same origin as the app or that the image response allows cross-origin access. My images are served via CDN (AWS S3), and they are configured to provide the proper Access-Control-Allow-Origin response headers when requested with the expected Origin header:
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
This would work fine, except my app also has the additional requirement of being able to run offline. To accomplish this, I'm listing my CDN asset urls in my application cache manifest:
CACHE MANIFEST
CACHE:
http://<host url here>/image.png
The problem I'm having is that, once the assets are being loaded from the appcache, I start getting Cross-origin image load denied by Cross-Origin Resource Sharing policy errors.
I've read that Chrome is supposed to send the appcache manifest origin along with the cache population requests, but based on my cursory explorations in chrome://net-internals, this does not appear to be happening in my case.
Here's what I'm seeing in chrome://net-internals/#events when the cache population request is made:
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
It seems that Chrome is not making the request with an Origin header, which means the CDN doesn't know to respond with the CORS headers. As a result (I think), Chrome caches the vanilla non-cross-origin-access response, and serves it from the appcache.
Any advice or insight would be very welcome! Thanks for reading.
I am afraid there is no answer. The bug to which you linked is not resolved - it is archived since a few years have passed without any action from the project members. Cross origin Application Cache requests do not include the Origin header.
You can create a new issue at crbug.com and it may get more attention. However, unless I am misunderstanding the thread (see the second compatibility risk paragraph), I think I read that Chrome (and maybe Safari?) is the only browser that supports cross origin sub resources within an Application Cache manifest. If you add your request into the Application Cache specification, all browsers (assuming there is consensus and support) may support this in the future. Improving a non standard behavior (in a non standard way) is probably not the way to go, so I would not count on Chrome implementing your request without a specification update. Also note that Application Cache has earned some pretty negative reputation and the way Google and Mozilla are pushing now is Service Worker (implemented in Chrome 40 and Opera 24 and under active development in Firefox).