Question

loading web font through CDN

Hello, im trying to use cloudfront as CDN for my site. and everything is fine accept loading my local webfonts (woff/woff2) though cloudfront. I search all over the net and understood its because of CORS and followed almost all guides out there but i dont know for what reason none actually works for me.

i added following in my server block

        location ~* \.(ttf|ttc|otf|eot|woff|woff2|svg|font.css)$ {
        add_header Access-Control-Allow-Origin $http_origin; # also tried with "*" but same result
        }

added custom Behaviors

Whitelist: origin

but still same result. only woff, woff2 types are denied by all browser.

maybe im doing something very tiny mistake. or missing a whole part here. could someone guide me on this?

best regards,


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

@newbie

FastCGI Cache takes the rendered output of a page – i.e. what you’d see when viewing the source of the page – and caches it to a static file on disk, or, if configured, to RAM (/dev/shm).

When a request comes through that matches the same URI, the cached page is served instead of the normal page that would be rendered by your script (i.e. WordPress).

Setting the cache to 100 MB isn’t necessarily a bad thing – it won’t affect performance or change the way things work, it just tells NGINX that the max size that the cache can be is 100 MB.

That said, it’d take quite a few cached pages to total 100 MB. When you run tests to check the page size of your page, that’s not the same size that’s getting cached as NGINX isn’t caching images and media to the cache. It’s caching the rendered page output (which links to images, media, and assets, such as your CSS, JS, etc).

While your page size in those tests may be, for example, 1-2MB or more, you’re cached page may only be a small fraction of that since all those other items are not cached by FastCGI Cache. Those items are cached by the users’ browser(s).

Think of FastCGI Cache as turning a dynamic page that has to hit the database on each page load in to a basic HTML file. Performance is multitudes better when it comes to serving static content, which is why a dynamic page load of 1-2 seconds may be reduced to 1/10th of that when serving a static page.

In terms of how FastCGI handles objects that are expired, that all depends on what you have set in the configuration.

For example, inactive defines the time it takes for an object to be removed from the cache after not being accessed for the defined time. If you set this to 30 minutes (for example), for an object to be removed from cache, it can not be accessed in that period of time. If an object is accessed between 1 second and 29 minutes and 59 seconds, it stays in the cache. This, of course, includes if you access it as FastCGI cache doesn’t differentiate between you or a visitor, nor are the settings to configure such caching.

To actually purge the cache, you’d want to look in to fastcgi_cache_purge.

http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_purge

That defines a method that can be used to purge or flush the cache. Of course, you’d have to set up your own code to send a PURGE request

Of course, using just that configuration, anyone could send a PURGE request and clear your cache, so you’d need to do some level of verification to make sure the request is coming from a certain IP or locally.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Did you restart nginx and clear the CloudFront cache? What is the domain?

@newbie

When testing the headers I noted in my previous response using add_header (which is used by the NGINX core) and more_set_headers (third-party module), I couldn’t reproduce the issue of not being able to load web fonts.

Can you post your entire server block so I can see the full configuration?

@newbie

NGINX can be a little finicky when it comes to single or double quotes, or a lack thereof. The same is true for missing : (some headers seem to work without, some don’t, hence finicky :-) ).

You may want to try using something such as:

add_header 'Access-Control-Allow-Origin: $http_origin';

or

add_header 'Access-Control-Allow-Origin' "$http_origin";

The second example is generally more common. Of course, once changes are made, you’ll want to restart or reload NGINX for the changes to take.