CORS在「備用」域名上的困難

我有一個Amazon CloudFront設置，指向一個S3存儲桶作爲CDN。我還有一個指向此CloudFront的備用域名（不在Route53上）。CORS在「備用」域名上的困難

我一直有麻煩的腳本中使用備用域名時通過CDN拉 - 但如果我用從CloudFront的控制面板原生一個，它的工作原理。

是不是有什麼特別的，我需要的不僅僅是設置域名CNAME指向亞馬遜的CloudFront的地址CORS工作做其他的？

2016-05-07 Ciel

如[告訴CloudFront的約你指着它的名字（http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html）？ –

我在設置Cloud Front時向域添加了域的URL。還有其他地方需要設置嗎？ – Ciel

您是否可以使用備用主機名直接從CloudFront下載？您是否僅將問題隔離到跨源請求？你有沒有試過使用'curl'來模擬一個跨域請求？ –

正確緩存Web請求的一個重要組成部分，是確保從緩存中提供的響應是在這個意義上「正確的」，如果它是否會匹配其本身產生的響應，對於同樣的要求。

這不是因爲它的聲音簡單，因爲反應可基於如果某些請求頭的內容。

CloudFront採用保守和安全的方法，在將請求轉發到原始服務器時剝去大多數請求標頭 - 如果服務器無法看到標頭，則無法使用標頭來改變其響應。

在CORS的情況下，原始服務器看到Origin:,Access-Control-Request-Headers:和Access-Control-Request-Method:標題是非常重要的，因此它可以做出相應的響應。

但轉發不必要的頭到原始服務器導致低效的高速緩存，因爲緩存的響應將只針對相同的將來的請求提供服務，包括相同的轉發標頭。

所以三個CORS要求在CloudFront的緩存行爲標題必須是「白名單」，讓他們將被轉發到源服務器（在這種情況下，S3）。

2016-05-09 13:02:25

謝謝你對我的耐心。確實，這些問題源於我自己的不足之處以及未能充分閱讀文檔 - 非常徹底。 – Ciel

回答