Missing support for Cross-Origin Resource Sharing headers is a big problem for some applications. For example, drawing images to a canvas from s3/cloudfront will unavoidably taint your canvas. (https://developer.mozilla.org/en/CORS_Enabled_Image)
Right now I'm proxying image requests to s3 through nginx, which is a terrible workaround.
We do the same thing for the same reason. Luckily we were able to split off a lot of our other content serving (same content, not to canvas elements) to a CDN which is backed by our origin servers. It's a little crazy, but is the best we can do until there's better CORS and custom SSL for Cloudfront.
we're planning to migrate Pictos Server [1] away from S3 and onto Cloud Files for this exact reason. IE9 refuses to use webfonts loaded from a different origin unless CORS allows it, something we can't easily do without adding EC2 to our deployment.
Comments
Missing support for Cross-Origin Resource Sharing headers is a big problem for some applications. For example, drawing images to a canvas from s3/cloudfront will unavoidably taint your canvas. (https://developer.mozilla.org/en/CORS_Enabled_Image)
Right now I'm proxying image requests to s3 through nginx, which is a terrible workaround.
The AWS forums has a topic on the issue started in 2009 (~200 replies so far...): https://forums.aws.amazon.com/thread.jspa?threadID=34281
We do the same thing for the same reason. Luckily we were able to split off a lot of our other content serving (same content, not to canvas elements) to a CDN which is backed by our origin servers. It's a little crazy, but is the best we can do until there's better CORS and custom SSL for Cloudfront.
we're planning to migrate Pictos Server [1] away from S3 and onto Cloud Files for this exact reason. IE9 refuses to use webfonts loaded from a different origin unless CORS allows it, something we can't easily do without adding EC2 to our deployment.
[1] http://pictos.cc/server/