Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-03T17:55:52.543Z
Answers.Text: 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.
Answers.UserDisplayName: Matt Stein
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-03T13:26:19.363Z
Answers.LastActivityDate: 2015-04-03T13:54:52.600Z
Answers.LastEditDate: 2017-05-23T12:38:53.957Z
Answers.UserDisplayName: André Elvan
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-03T17:54:55.463Z
Answers.LastActivityDate: 2015-04-03T17:54:55.463Z
Answers.UserDisplayName: Matt Stein
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T21:55:07.587Z
Comments.Text: Just to verify your theory, if you remove the CORS stuff, does it work again?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T21:57:06.023Z
Comments.Text: 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.
Comments.UserDisplayName: Matt Stein
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T21:58:18.163Z
Comments.Text: 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)?
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T22:01:32.980Z
Comments.Text: 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."
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T22:21:52.707Z
Comments.Text: 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.
Comments.UserDisplayName: Natetronn
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T22:37:09.187Z
Comments.Text: Thanks for the ASCII tip @LindseyD—I scoured SE but not G+. And thanks for the nginx suggestion @Natetronn!
Comments.UserDisplayName: Matt Stein
Tags: <control-panel><nginx>
Title: Why might the admin panel's font 404?
ThreadText: # 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:
  
  ![The request, as seen in Postman.](https://i.sstatic.net/QKfXc.png)
  
  ![Broken icon font :(](https://i.sstatic.net/zSBYa.png)
  
  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 username_0 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 @username_2—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](https://stackoverflow.com/questions/5238377/nginx-location-priority) 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
  
  username_4 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 username_4 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.
  
  
  ---
  
  