在跨域请求字体文件时,您必须确保允许域请求使用CORS标头访问字体文件:
但是,在请求图像时,无论是img元素还是元素,都不需要这样做background-image.
为什么这些文件类型具有不同的安全性？
nat*_*evw 11
扩展 @Marged 提供的链接，浏览器对字体文件强制实施 CORS，因为规范规定它们必须这样做：
\n\n\n\n\n对于字体加载，用户代理必须使用 @font-face 规则中定义的 URL 的 [FETCH] 规范定义的潜在支持 CORS 的获取方法。获取时，用户代理必须使用“匿名”模式，将引用来源设置为样式表的 URL，并将来源设置为包含文档的 URL。
\n
\xe2\x80\xa6并直接注释：
\n\n\n\n\n这对作者来说意味着字体通常不会跨源加载 [\xe2\x80\xa6]
\n
但这并不能真正回答您的问题，因为规范本身并没有给出为什么必须存在此要求的理由。
\n\n链接的 Firefox 线程是众多讨论之一，并提到了“提高新规范的安全性”的一般理由：
\n\n\n\n\n这里有一个更广泛的讨论，即“新”资源类型应该默认为什么，它们是否应该简单地默认为图像和脚本允许的相同的不受限制的链接，或者是否应该默认限制它们并具有放松的能力通过 CORS
\n
但听起来在这个特殊案例中，驱动因素是政治原因。也就是说，它考虑了并非“纯技术性”的担忧。正如一位实施者所总结的：
\n\n\n\n\n主要原因是字体供应商希望 Web 作者将字体的使用限制在自己的网站上，而 Web 作者无法轻松可靠地做到这一点，除非我们默认提供同源限制。
\n
这在其他实现者的错误跟踪器讨论中也得到了证实，例如：
\n\n\n\n据我所知，[浏览器]不这样做的主要影响是网站无意中违反了其字体许可证，并且作者对部署字体的正确方法感到困惑。
\n
| 归档时间： |
|
| 查看次数： |
383 次 |
| 最近记录： |