Why might the admin panel's font 404?

Question

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?

Answer 1

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 *;
}

Answer 2

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.