在 Cloudfront 缓存对象上设置 Access-Control-Allow-Origin

Question

由于“bad URI or cross-site access not allowed”问题，通过 Cloudfront 提供的字体在 Firefox 中被破坏。为了解决这个问题，我知道我需要将“Access-Control-Allow-Origin”标头设置为通配符或源域。

我遇到的问题是 Cloudfront 似乎不接受来自源的标头。

例如，以下是我在 ping 服务器以获取字体时获得的标头列表：

curl -I -s "https://mysite.com/wp-content/themes/my-theme/includes/fonts/ProximaNova-Reg-webfont.ttf"
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jan 2014 16:03:03 GMT
Content-Type: application/x-font-ttf
Content-Length: 44992
Last-Modified: Tue, 28 Jan 2014 22:21:41 GMT
Connection: keep-alive
ETag: "52e82d75-afc0"
Expires: Thu, 29 Jan 2015 16:03:03 GMT
Cache-Control: max-age=31536000
Access-Control-Allow-Origin: https://mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3600
Accept-Ranges: bytes

这个响应看起来一切都很好；但是，当我 ping Cloudfront 获取相同的资源时，我得到：

curl -I -s "https://ds6dj5kp03o39.cloudfront.net/wp-content/themes/my-theme/includes/fonts/ProximaNova-Reg-webfont.ttf"
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 44992
Connection: keep-alive
Date: Wed, 29 Jan 2014 16:22:30 GMT
Server: Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o
Last-Modified: Wed, 22 Jan 2014 02:44:45 GMT
ETag: "5d633-afc0-4f0861b87a140"
Accept-Ranges: bytes
Cache-Control: max-age=3600
Expires: Wed, 29 Jan 2014 17:22:30 GMT
X-Cache: Miss from cloudfront
Via: 1.1 850e11212c3f83bfb138469e9b3b7718.cloudfront.net (CloudFront)
X-Amz-Cf-Id: M4qkj9FwjdAUW91U4WeZzxEI0m7vOmiQvryS55WwoeU5Ks11IC71ig==

似乎所有原始标头都被完全忽略了。我的问题是，如何让 Cloudfront 接受我的资产标头，尤其是关键的“Access-Control-Allow-Origin”标头？

感谢您的帮助！

Answer 1

如果您稍后再进行此操作，并且遇到此问题的自定义来源已经正确地为 Access-Control-Allow-Origin 标头提供服务，那么我检查/尝试了以下两件事：

1. 检查您的 nginx 或 apache 配置是否有引号中的 *，如果有 确实，请尝试删除它们。
2. 确保您传递的是正确的 woff 和 ttf 文件的内容类型。这是我最快的链接 在这个主题上找到 - https://github.com/fontello/fontello/wiki/How-to-setup-server-to-serve-fonts

阿帕奇

要为字体文件设置正确的 mime 类型，请将以下行添加到配置中：

AddType application/vnd.ms-fontobject    .eot
AddType application/x-font-ttf           .ttf
AddType application/font-woff            .woff

如果您无法编辑配置，请在您的文件夹中创建 .htaccess 文件 项目并在那里添加行。

对于 CORS 标头，添加以下代码：

<FilesMatch ".(eot|ttf|otf|woff)">
  Header set Access-Control-Allow-Origin "*"
</FilesMatch>

进行这些更改后，您需要运行service apache2 restart，如果您收到错误Invalid command 'Header'，则表示您尚未在Apache 中启用mod_header 模块，您可以使用a2enmod headers 执行此操作

nginx

默认情况下，nginx 没有默认的字体 mime 类型，并且 mimy 错误 输入.eot 文件。进入带有配置的文件夹并找到 mime 的位置 类型被污染。通常，在 mimes.conf 文件中。

搜索.eot 并用它串起来。 在下面添加字符串：

application/vnd.ms-fontobject    eot;
application/x-font-ttf           ttf;
application/font-woff            woff;

对于 CORS 标头，将类似这样的内容添加到您的虚拟主机配置中

location ~* \.(eot|ttf|woff)$ {
    add_header Access-Control-Allow-Origin *;
}

Answer 2

在其默认配置中，CloudFront 不会检查标头或缓存其值。对您来说，一个可能的罪魁祸首是您的资源首先在没有“Origin”标头的情况下被请求，因此 S3 没有提供 CORS 标头作为响应。响应被缓存，当您稍后发出跨域请求时，缓存的响应会在没有它们的情况下提供。

您可以将 CloudFront 配置为将 Origin 标头转发到 S3 并为不同的标头值缓存不同的响应，这将导致 CloudFront 在需要时缓存 CORS 标头。见http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors。

Answer 3

您所做的是正确的，但 CloudFront 会缓存结果，因此您将获得旧的缓存版本。 您可以在标题中看到这一点： 来自您的网站：

最后修改时间：格林威治标准时间 2014 年 1 月 28 日星期二 22:21:41

来自云端：

最后修改时间：格林威治标准时间 2014 年 1 月 22 日星期三 02:44:45

现在，如何让它再次工作：

a) 等待对象过期，然后再次请求。 CloudFront 将随后对其进行更新。

b) 使用您的 amazon aws 控制台 > cloudfront > distribution > Invalidations 使对象无效。有关如何使用此功能的详细信息，请参阅http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

c) 更改名称或开始使用文件的版本名称，例如ProximaNova-Reg-webfont_2.ttf

Answer 4

您的存储桶有一个明确的配置来动态评估 CoRS 标头。

1. 见AWS CORS docs
2. 也是他们使用的detailed explanation

尝试为 CF 或 S3 设置 CORS 标头或其他方式将被丢弃，因为这会破坏它们的缓存模型。