CORS与Amazon S3上的最新Chomium和Google Canary的问题 [英] CORS problems with Amazon S3 on the latest Chomium and Google Canary

查看：278
本文介绍了CORS与Amazon S3上的最新Chomium和Google Canary的问题的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我们的网站在使用最新版本的Chromium（版本33.0.1722.0 - 237596）和Chrome Canary在Amazon S3存储桶上加载CSS和JS资源时遇到问题。
它适用于任何其他浏览器，包括当前的Chrome（31.0.1650.57）。



错误是：



原文脚本 https://mybucket.s3.amazonaws.com '已被跨源资源共享策略阻止加载：在请求的资源上不存在Access-Control-Allow-Origin头。原因 https://app.example.com 因此不允许访问。



资源桶上的S3 CORS配置为：

 < ;? xml version =1.0encoding =UTF-8？> 
< CORSConfiguration xmlns =http://s3.amazonaws.com/doc/2006-03-01/> 
< CORSRule> 
< AllowedOrigin> *< / AllowedOrigin> 
< AllowedMethod> GET< / AllowedMethod> 
< MaxAgeSeconds> 300000< / MaxAgeSeconds> 
< AllowedHeader>授权< / AllowedHeader> 
< / CORSRule> 
< / CORSConfiguration>

这是Chromium的错误吗？
在最新的CORS规范上发生了变化？

解决方案

很可能， S3 / CloudFront / CORS的已知问题。我找到的最好的解决方案是有一个代理S3和CloudFront之间的应用程序，总是添加适当的CORS头到对象，因为他们回来。



S3 + CloudFront在将CORS资产提供给不同的网络浏览器时出现故障。




  • 并非所有浏览器都需要CORS来处理网络字体和其他静态资源。如果其中一个浏览器发出请求，S3将不发送CORS头，CloudFront将缓存（无用的）响应。

  • CloudFront不支持 Vary：Origin 标题，因此对于 AllowedOrigin 值使用 * ，并且将只缓存多个 AllowedOrigin 值中的第一个。



结束，这两个问题使S3 + CloudFront成为一个用于使用CORS与（快速）CDN解决方案的不可靠的解决方案 - 至少开箱即用。防弹解决方案是创建一个简单的应用程序，代理S3和CloudFront之间的请求，总是添加必要的CORS头，以便CloudFront总是缓存它们。



冷缓存




  • ←浏览器从CloudFront请求静态资源。

  • ←CloudFront未命中，

  • ←代理应用程序将请求传递到S3。

  • →S3会回应代理应用程序

  • →代理应用程序添加正确的CORS头（无论S3是否已发送）。代理应用程序会回应CloudFront。

  • →CloudFront缓存结果并回复浏览器。



针对热缓存请求




  • ←浏览器从CloudFront请求静态资源。

  • →CloudFront命中，并回应浏览器。



是的，这是一个广为人知的广泛问题： / p>



我可以说我们的S3和CloudFront团队非常了解这里讨论的问题。通过写一个简单的应用程序，可以充当S3和CloudFront之间的代理，您可以在CloudFront缓存它们之前手动注入所有正确的CORS响应头。



如果你总是在Firefox中工作，那么你可能不会注意到这个问题 - CloudFront将始终缓存您启用CORS的响应。如果您主要在Safari或Chrome中工作，当您切换回需要这些标头的浏览器（Firefox和IE）时，您会更常看到它。此外，如果您有单独的开发/暂存/生产环境，您可能会更频繁地遇到多原始问题。


Our website is having problems loading CSS and JS resources on a Amazon S3 bucket with the very latest version of Chromium (Version 33.0.1722.0 - 237596) and Chrome Canary. It works well with any of the other browsers including the current Chrome (31.0.1650.57).

The error is:

Script from origin 'https://mybucket.s3.amazonaws.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://app.example.com' is therefore not allowed access.

Our S3 CORS configuration on the resource bucket is:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>300000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Is it a bug with Chromium? Did something change on the latest CORS spec?

解决方案

In all likelihood, you're running into a very well-known problem with S3/CloudFront/CORS. The best solution I've been able to find is to have an app that proxies between S3 and CloudFront, always adding the appropriate CORS headers to the objects as they come back.

S3 + CloudFront are broken when it comes to serving CORS assets to different web browsers. The issue is two-fold.

  • Not all browsers require CORS for web fonts and other static assets. If one of these browsers makes the request, S3 won't send the CORS headers, and CloudFront will cache the (unhelpful) response.
  • CloudFront doesn't support the Vary: Origin header, so it has issues with using * for the AllowedOrigin value, and will only cache the first of multiple AllowedOrigin values.

In the end, these two issues make S3 + CloudFront an untenable solution for using CORS with a (fast) CDN solution — at least, out of the box. The bulletproof solution is to create a simple app that proxies the requests between S3 and CloudFront, always adding the requisite CORS headers so that CloudFront always caches them.

Request against a "Cold" cache

  • ← Browser requests a static asset from CloudFront.
  • ← CloudFront misses, and hits its origin server (a Proxy App).
  • ← The Proxy App passes the request to S3.
  • → S3 responds back to the Proxy App.
  • → The Proxy App adds the correct CORS headers (whether S3 had sent them or not). The Proxy App responds back to CloudFront.
  • → CloudFront caches the result and responds back to the browser.

Request against a "Warm" cache

  • ← Browser requests a static asset from CloudFront.
  • → CloudFront hits, and responds back to the browser.

Yes, this is a well-known, widespread issue:

I can say that our S3 and CloudFront teams are well-aware of the issues discussed here. By writing up a simple app that can act as a proxy between S3 and CloudFront, you can manually inject all of the correct CORS response headers before CloudFront caches them.

If you always work in Firefox, then you likely won't notice the issue — CloudFront will always be caching your CORS-enabled responses. If you work primarily in Safari or Chrome, you'll see it much more often when you switch back to a browser which requires these headers (Firefox and IE). Also, if you have separate development/staging/production environments, you're likely to run into the multi-origin issues more often.

这篇关于CORS与Amazon S3上的最新Chomium和Google Canary的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其它移动开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆