由于" 不允许错误的URI或跨站点访问 "问题,通过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"标题?
谢谢您的帮助!
如果您以后再来这个问题,并且问题是自定义来源已经正确地提供了Access-Control-Allow-Origin标头,那么我检查/尝试了两件事:
检查你的nginx或apache配置是否有*引号,如果有,请尝试删除它们.
确保您为woff和ttf文件传递了正确的内容类型.这是我在这个主题上找到的最快的链接 - https://github.com/fontello/fontello/wiki/How-to-setup-server-to-serve-fonts
阿帕奇
要为字体文件设置正确的mime-types,请将此行添加到config:
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类型,也没有.eot
文件的错误mimy类型.得到配置文件夹,找到mime类型被污染的地方.通常,那是在mimes.conf文件中.
.eot
用它搜索和字符串.添加以下字符串:
application/vnd.ms-fontobject eot; application/x-font-ttf ttf; application/font-woff woff;
对于CORS标头,请将此类内容添加到vhost配置中
location ~* \.(eot|ttf|woff)$ { add_header Access-Control-Allow-Origin *; }
你所做的是对的,但CloudFront会缓存结果,因此你得到了旧的缓存版本.您可以在标题中看到:来自您的网站:
最后修改时间:星期二,2014年1月28日22:21:41 GMT
来自cloudfront:
Last-Modified:Wed,22 Jan 2014 02:44:45 GMT
现在,如何让它再次运作:
a)等待对象过期,然后再次请求它.然后CloudFront将对其进行更新.
b)使用您的amazon aws控制台> cloudfront>分发>失效来使对象失效.有关如何使用此功能的详细信息,请参阅http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
c)更改名称或开始使用文件的版本化名称,例如ProximaNova-Reg-webfont_2.ttf
在默认配置中,CloudFront不检查标头或缓存其值.您可能的罪魁祸首是您的资源首先被请求没有"Origin"标头,因此S3没有提供CORS标头作为响应.响应被缓存,当您稍后进行跨源请求时,缓存的响应将在没有它们的情况下提供.
您可以将CloudFront配置为将Origin标头转发到S3并缓存不同标头值的不同响应,这将导致CloudFront在需要时缓存CORS标头.见http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors.