Chrome中CDN背后的woff2字体出现CORS问题 [英] CORS Issue with woff2 fonts behind CDN in Chrome

问题描述

我有一个带有Cloudfront CDN的S3存储桶。在那个存储桶中，我有一些woff2字体，它们被自动标记为内容类型 octet-stream 。尝试从实时生产网站上的CSS文件加载该字体时，出现以下错误：

I have an S3 Bucket fronted with a Cloudfront CDN. In that bucket, I have some woff2 fonts that were automatically tagged with the content type octet-stream. When trying to load that font from a CSS file on a live production website, I get the following error:

Access to Font at 'https://cdn.example.com/fonts/my-font.woff2' from origin 
'https://www.live-website.com' has been blocked by CORS policy: 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'https://www.live-website.com' is therefore not allowed access.

事实是，卷曲表明 Access-Control-Allow-存在Origin

HTTP/1.1 200 OK
Content-Type: binary/octet-stream
Content-Length: 98488
Connection: keep-alive
Date: Wed, 08 Aug 2018 19:43:01 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Last-Modified: Mon, 14 Aug 2017 14:57:06 GMT
ETag: "<redacted>"
Accept-Ranges: bytes
Server: AmazonS3
Age: 84847
X-Cache: Hit from cloudfront
Via: 1.1 <redacted>
X-Amz-Cf-Id: <redacted>

在Firefox中一切正常，因此我认为Chrome浏览器正在进行额外的验证，该行为阻止了我的字体。

Everything is working fine in Firefox, so I guess that Chrome is doing an extra validation that blocks my font.

推荐答案

事实证明，问题实际上出在 Content-Type 。一旦将内容类型更改为 application / font-woff2 并使这些 woff2 文件的缓存无效，所有内容顺利进行。

Turns out that the problem was actually with the Content-Type. As soon as I changed the content type to application/font-woff2 and invalidated the cache of these woff2 files, everything went through smoothly.

这篇关于Chrome中CDN背后的woff2字体出现CORS问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！