本文介绍了我可以为域和其子域上的所有页面设置一个Access-Control-Allow-Origin头吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图使用我合法允许使用的webfont,但不发布。我托管的字体文件在一个单独的域用于静态内容。这两个域是不相关的(一个不是另一个的子域)。假设使用webfont的网站是 example.com ,托管它的网站是 example.net

我在 example.net

上的.htaccess文件中尝试了这个方法

 < FilesMatch\。(ttf | otf | eot | woff | svg)$> 
< IfModule mod_headers.c>
标题集Access-Control-Allow-Originexample.com
< / IfModule>
< / FilesMatch>

但是,这允许字体只能在首页 code> example.com 。我再试一次:

 头文件集Access-Control-Allow-Originexample.com/*

现在字体可以在 example.com 首页,这当然不是我想要的。



我找不到这个标题的任何文件。我真正想要的是允许 example.com www.example.com c>(或者,对于很好的测量, *。example.com )。有没有简单的方法来做到这一点?



正在寻找我发现的文档,




  • 很多关于这个标题如何与ajax交互的东西,

  • 很多简短的注释说明它对于webfonts是必要的(至少在Firefox中)。



我没有找到任何有关头本身的语法的文档,或者如何指定域的变体。



根据,我尝试过:

 < FilesMatch\。(ttf | otf | eot | woff | svg)$> 
< IfModule mod_headers.c>
SetEnvIf源http(s)?://(www\。)?(example.com)$AccessControlAllowOrigin = $ 0 $ 1
头添加访问控制允许原始%{AccessControlAllowOrigin} e env = AccessControlAllowOrigin
头集合Access-Control-Allow-Credentials true
< / IfModule>
< / FilesMatch>

我的理解是,这将为每个请求设置一个单独的标题,允许每个请求页面单独使用字体。用Firebug检查,看起来总是 http://example.com ,在首页和其他地方。尽管如此,这个作品,但让我困惑。相关问题显示,。他的问题表明,对他来说,它实际上是为每个请求页发送一个不同的头,因此 HTTP 304未修改响应打破。他的解决方案是向 .htaccess 添加总是指令,但是对于我来说,导致 HTTP 500 错误。



因为它现在,它的工作,我认为 example.com 切换到HTTPS(很快就会如此)。然而,我不禁感到它是过于复杂。它每次设置相同的标题,但是使用复杂的模式匹配这样做。此外,虽然我还没有任何问题与 HTTP 304未修改响应(事实上,我还没有看到任何这样的响应:浏览器根本不请求

解决方案

如上所述,我们可以看到, ,您只能在 Access-Control-Allow-Origin 头(或 * / code>)。



所以是的,你需要根据什么域请求网站不同设置标头。这就是为什么您发布的apache配置代码段试图在请求的 Origin 标头上匹配此:

  http(s)?://(www \。 )?(example.com)$ 

$ 匹配字符串的结尾。因此,此正则表达式将匹配来自 http://www.example.com http://example.com 和它们的https相同,但不是 example.com/bla 。这应该很好,因为请求的 Origin 头以及 Access-Control-Allow-Origin 头的响应主机,而不包含子页面。



因此,当您在页面 http://example.com/about-us 时,浏览器将发送类似以下请求以从 http://cdn.net/myfont.otf

  GET / myfont.otf HTTP / 1.1 
主机:http://cdn.net
原产地:http://example.com

在这里,服务器将在Origin头部进行模式匹配并返回:

  Control-Allow-Origin:http://example.com 


I am trying to use a webfont which I am legally permitted to use, but not to distribute. I am hosting the font files on a separate domain used for static content. The two domains are unrelated (one is not a subdomain of the other). Let’s say that the site using the webfont is example.com and the site hosting it is example.net.

I tried this in the .htaccess file on example.net

<FilesMatch "\.(ttf|otf|eot|woff|svg)$">
  <IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "example.com"
  </IfModule>
</FilesMatch>

However, this allows the font to work only on the homepage of example.com. I tried again:

    Header set Access-Control-Allow-Origin "example.com/*"

Now the font works on example.com everywhere except the homepage, which is (of course) not what I wanted.

I can’t find any documentation for this header. What I really want is to allow all pages on example.com and www.example.com (or, for good measure, *.example.com). Is there a simple way to do this? I’m guessing that the header takes some kind of regex.

Looking for documentation I found,

  • a lot of stuff about how this header interacts with ajax,
  • a lot of brief notes saying that it’s necessary for webfonts (at least in Firefox).

I did not find any documentation about the syntax of the header itself, or how to specify variants of a domain.

Based on an answer to a related question, I tried this:

<FilesMatch "\.(ttf|otf|eot|woff|svg)$">
    <IfModule mod_headers.c>
        SetEnvIf Origin "http(s)?://(www\.)?(example.com)$" AccessControlAllowOrigin=$0$1
        Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header set Access-Control-Allow-Credentials true
    </IfModule>
</FilesMatch>

My understanding was that this would set a separate header for each request, allowing each requesting page individually to use the font. Checking with Firebug, though, it looks like the header is always http://example.com, both on the homepage and elsewhere. Nonetheless, this works, but leaves me confused. A related question shows that a similar setup was not working for someone else. His question suggests that for him, it actually was sending a different header for each requesting page, and that HTTP 304 Not Modified responses were therefore breaking. His solution was to add an always directive to the .htaccess, but for me that resulted in HTTP 500 errors.

As it is now, it’s working, and I think will continue to work when example.com switches to HTTPS (as it will shortly). However, I can’t help but feel that it’s overly complicated. It’s setting the same header each time, but is using complex pattern-matching to do so. Also, while I haven’t yet any problems with HTTP 304 Not Modified responses (in fact, I’ve not yet seen any such responses: the browser simply doesn’t request the font files at all until I clear the cache), I worry that I might see them in future.

解决方案

As stated by the CORS spec, you can have only one domain in the Access-Control-Allow-Origin header (or * or null).

So yes, you need to set the header differently depending on what domain is requesting the site. That's why the apache config snippet you posted tries to match on the Origin header of the request with this regex:

http(s)?://(www\.)?(example.com)$

The $ matches end of string. So this regex will match requests from http://www.example.com, http://example.com and their https equivalents, but not example.com/bla. This should be fine since the Origin header of the request, as well as the Access-Control-Allow-Origin header of the response should contain only the host and not the subpages.

So when you're on the page http://example.com/about-us, the browser will send something like the following request to get the font from http://cdn.net/myfont.otf:

GET /myfont.otf HTTP/1.1
Host: http://cdn.net
Origin: http://example.com

There the server will patternmatch on the Origin header and return with:

Access-Control-Allow-Origin: http://example.com

这篇关于我可以为域和其子域上的所有页面设置一个Access-Control-Allow-Origin头吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-23 10:21