<p>The request for the craft font needs to be rewritten, since the actual file is (usually) outside of the public web root. Usually, this will be handled by the location block in your nginx configuration that rewrites requests to index.php. After you added the location block that adds the CORS header, though, all requests for font files are processed by this block only (see <a href="https://stackoverflow.com/questions/5238377/nginx-location-priority">this thread</a> for more on location priority). nginx only processes one location block pr request, it doesn't "add them up". The best solution would probably be to make the location block for adding the CORS headers more specific, so that the regexp doesn't match the Craft fonts.</p>

<p>Here's an example on what I did on a previous project where the fonts were inside my /assets folder:</p>

<pre><code>location ~* ^/assets/.*\.(?:eot|ttf|woff)$ {
   add_header Access-Control-Allow-Origin *;
}
</code></pre>

CC BY-SA 3.0
2015-04-03T17:55:52.543Z
Thanks for this answer! You were right, and we ended up taking a slightly different approach (adding `try_files` instead of excluding Craft fonts) to fix the problem.
Matt Stein
CC BY-SA 3.0
2015-04-03T13:26:19.363Z
2015-04-03T13:54:52.600Z
2017-05-23T12:38:53.957Z
André Elvan
<p>André was right that the font-specific location block needed adjustment, and in this case the block specifically needed help figuring out how to process font files <em>outside</em> the web root. Rather than adjust the rule to ignore Craft's fonts, we ended up adding <code>try_files $uri $uri/ @rewrites;</code> after setting the response headers...</p>

<pre><code>location ~* \.(otf|ttf|eot|woff)$ {
    add_header "Access-Control-Allow-Origin" "$cors_permitted_domain";
    add_header 'Vary' 'Origin';

    try_files $uri $uri/ @rewrites;
}
</code></pre>

<p>I had lots of help getting here, but my understanding is that the location block processed the font request but wasn't properly serving Craft's control panel fonts because nginx locations need to cascade sufficiently for that to happen. As André noted, the font location block was matched for the request so it lost its ability to creatively serve assets that work fine in other <code>location</code> blocks.</p>

CC BY-SA 3.0
2015-04-03T17:54:55.463Z
2015-04-03T17:54:55.463Z
Matt Stein
<p>The admin panel's icon font refuses to load, throwing a 404 along with the full body of the font file. The result looks like this:</p>

<p><img src="https://i.sstatic.net/QKfXc.png" alt="The request, as seen in Postman."></p>

<p><img src="https://i.sstatic.net/zSBYa.png" alt="Broken icon font :("></p>

<p>I don't know nginx well, but we recently added a change to the config to categorically lock down cross-domain font usage where <code>suddenvalleydevelopment.com</code> is our primary domain and <code>balboatowers.com</code> is another one authorized to use fonts. Relevant lines:</p>

<pre><code>map $http_origin $cors_permitted_domain {
    hostnames;
    default suddenvalleydevelopment.com;
    .suddenvalleydevelopment.com $http_origin;
    .balboatowers.com $http_origin;
}

location ~* \.(otf|ttf|eot|woff)$ {
    add_header "Access-Control-Allow-Origin" "$cors_permitted_domain";
    add_header 'Vary' 'Origin';
}
</code></pre>

<p>I'm pretty sure this created the problem you see above, but I don't understand <em>how</em> and therefore how to fix it. We know that Craft stores its own font files at craft/app/resources/fonts, and not in public/admin/resources/fonts like you'd expect from the request.</p>

<p><strong>How does Craft get its icon font (Craft.woff, etc.) to the browser, and why would the CORS provision interfere with that?</strong></p>

CC BY-SA 3.0
2015-03-31T21:55:07.587Z
Just to verify your theory, if you remove the CORS stuff, does it work again?
Brad Bell
CC BY-SA 3.0
2015-03-31T21:57:06.023Z
I'm not able to change the nginx config (and can't run the same one locally), but I *did* drop the files into public/admin/resources/fonts and that works. Not exactly scientific, but that's as close as I could get to isolating the problem.
Matt Stein
CC BY-SA 3.0
2015-03-31T21:58:18.163Z
I've seen this before, though I don't remember when or where. Have you scoured the [Google+ Community](https://plus.google.com/communities/106505340287442511226)?
Lindsey D
CC BY-SA 3.0
2015-03-31T22:01:32.980Z
Per Daniel Stein in [this thread](https://plus.google.com/107495427250293754476/posts/8X7FcwFhvpX)... "I experienced the same glitch when uploading the Craft directory in ASCII mode (using Transmit). Switching to 'auto' and re-uploading fixed the issue."
Lindsey D
CC BY-SA 3.0
2015-03-31T22:21:52.707Z
I think it would be helpful if you test your domains in the location itself instead of outside like this [thread](http://stackoverflow.com/a/27879729/585191) demonstrates.
Natetronn
CC BY-SA 3.0
2015-03-31T22:37:09.187Z
Thanks for the ASCII tip @LindseyD—I scoured SE but not G+. And thanks for the nginx suggestion @Natetronn!
Matt Stein
<control-panel><nginx>
Why might the admin panel's font 404?
# Why might the admin panel's font 404?

(Asked by: username_0 on 2015-03-31)

The admin panel's icon font refuses to load, throwing a 404 along with the full body of the font file. The result looks like this:


I don't know nginx well, but we recently added a change to the config to categorically lock down cross-domain font usage where suddenvalleydevelopment.com is our primary domain and balboatowers.com is another one authorized to use fonts. Relevant lines:
map $http_origin $cors_permitted_domain {
    hostnames;
    default suddenvalleydevelopment.com;
    .suddenvalleydevelopment.com $http_origin;
    .balboatowers.com $http_origin;
}

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

I'm pretty sure this created the problem you see above, but I don't understand how and therefore how to fix it. We know that Craft stores its own font files at craft/app/resources/fonts, and not in public/admin/resources/fonts like you'd expect from the request.
How does Craft get its icon font (Craft.woff, etc.) to the browser, and why would the CORS provision interfere with that?

**Tags:** control-panel, nginx

> **Comments:**
> **username_1**: Just to verify your theory, if you remove the CORS stuff, does it work again?  
> **username_0**: I'm not able to change the nginx config (and can't run the same one locally), but I *did* drop the files into public/admin/resources/fonts and that works. Not exactly scientific, but that's as close as I could get to isolating the problem.  
> **username_2**: I've seen this before, though I don't remember when or where. Have you scoured the [Google+ Community](https://plus.google.com/communities/106505340287442511226)?  
> **username_2**: Per Daniel Stein in [this thread](https://plus.google.com/107495427250293754476/posts/8X7FcwFhvpX)... "I experienced the same glitch when uploading the Craft directory in ASCII mode (using Transmit). Switching to 'auto' and re-uploading fixed the issue."  
> **username_3**: I think it would be helpful if you test your domains in the location itself instead of outside like this [thread](http://stackoverflow.com/a/27879729/585191) demonstrates.  
> **username_0**: Thanks for the ASCII tip @LindseyD—I scoured SE but not G+. And thanks for the nginx suggestion @username_3!  

---

## 2 answers

### Answer by username_4 on 2015-04-03. Score: 4 | Accepted answer

The request for the craft font needs to be rewritten, since the actual file is (usually) outside of the public web root. Usually, this will be handled by the location block in your nginx configuration that rewrites requests to index.php. After you added the location block that adds the CORS header, though, all requests for font files are processed by this block only (see this thread for more on location priority). nginx only processes one location block pr request, it doesn't "add them up". The best solution would probably be to make the location block for adding the CORS headers more specific, so that the regexp doesn't match the Craft fonts.
Here's an example on what I did on a previous project where the fonts were inside my /assets folder:
location ~* ^/assets/.*\.(?:eot|ttf|woff)$ {
   add_header Access-Control-Allow-Origin *;
}

> **Comments:**
> **username_0**: Thanks for this answer! You were right, and we ended up taking a slightly different approach (adding `try_files` instead of excluding Craft fonts) to fix the problem.  

---

### Answer by username_0 on 2015-04-03. Score: 1

André was right that the font-specific location block needed adjustment, and in this case the block specifically needed help figuring out how to process font files outside the web root. Rather than adjust the rule to ignore Craft's fonts, we ended up adding try_files $uri $uri/ @rewrites; after setting the response headers...
location ~* \.(otf|ttf|eot|woff)$ {
    add_header "Access-Control-Allow-Origin" "$cors_permitted_domain";
    add_header 'Vary' 'Origin';

    try_files $uri $uri/ @rewrites;
}

I had lots of help getting here, but my understanding is that the location block processed the font request but wasn't properly serving Craft's control panel fonts because nginx locations need to cascade sufficiently for that to happen. As André noted, the font location block was matched for the request so it lost its ability to creatively serve assets that work fine in other location blocks.


---

