Icons fail to load #1881

sarahboyce · 2025-01-19T15:14:22Z

Noticed that icons are not loading on djangoproject.com (at least for me: on desktop, firefox, on mobile Chrome, Android).
They work on code.djangoproject.com and docs.djangoproject.com for mobile, they work in incognito mode 👍

Errors:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://docs.djangoproject.com’).

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://docs.djangoproject.com’).

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0

Screenshots with broken icons

Desktop:

Mobile:

The text was updated successfully, but these errors were encountered:

sarahboyce · 2025-01-20T06:27:56Z

e51e74b is possibly related (@adamzap)

pauloxnet · 2025-01-20T11:04:37Z

Noticed that icons are not loading on djangoproject.com on mobile (at least for me: Chrome, Android).

I can see icons on mobile 👍

I tested the website with Android 15 on Pixel 7.

Chrome 132

Firefox 134

@sarahboyce what version of Phone/OS/Browser are you experiencing the issue?

sarahboyce · 2025-01-20T11:09:55Z

Android 14, Chrome 132

adamzap · 2025-01-20T15:17:15Z

@sarahboyce Is this reproducible for you? I'm not exactly sure how assets work on production, but I'm assuming this is a one-time, cache-related thing.

sarahboyce · 2025-01-20T15:23:17Z

I still have this with cleared cache, it's been this way for a few days

nessita · 2025-01-20T16:51:17Z

I still have this with cleared cache, it's been this way for a few days

Is it the same if you try an incognito window or another browser like Firefox? I can't reproduce either 🤔

sarahboyce · 2025-01-20T17:01:47Z

Works on incognito 👍
This issue also is fine with incognito: #1887
So perhaps resolving those errors will resolve both issues for me

adamzap · 2025-01-20T17:12:16Z

Ah, given your comment in #1887, it seems like a production configuration issue, right? I wonder why it's not happening for the rest of us though.

adamzap · 2025-01-20T21:36:18Z

Since the discussion seems to be happening here, this is @sarahboyce's comment from #1887 showing the console errors related to this issue:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://docs.djangoproject.com’).

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://docs.djangoproject.com’).

downloadable font: download failed (font-family: "FontAwesome" style:normal weight:400 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://static.djangoproject.com/fonts/fontawesome-webfont.d95d6f5d5ab7.woff?v=4.2.0

The asset URL works fine for me. It's odd to me that https://docs.djangoproject.com is referenced here. I wonder if there is some host confusion happening?

For what it's worth, this header seems a bit odd to me too, but I should revisit the docs:

Anyway, these are just initial ideas. I hope to have some time later this week to debug this if the solution is not obvious to someone else.

sarahboyce · 2025-01-21T08:07:17Z

I added a screenshot of the broken link for me and this is cached until Dec 2037. I wonder if @bmispelon can do anything here 🤔

bmispelon · 2025-01-21T19:39:02Z

This is definitely confusing 🤔

In case that helps, here's the relevant (I think) portion of the nginx configuration for static.djangoproject.com:

map $http_origin $sanitized_origin {
	"~*^https://.+\.djangoproject\.com$"	$http_origin;
	default static.djangoproject.com;
}

server {
	listen [::]:443 ssl;
	server_name static.djangoproject.com;

	location / {
		gzip on;
		gzip_vary on;
		alias /var/www/static/;
		if ($uri ~* ".*\.[a-f0-9]{12,}\.(css|js|png|jpg|jpeg|gif|ico|woff|ttf|otf|svg|scss|map|txt)" ) {
			expires max;
		}
		include /etc/nginx/security_headers;
		# The 'Origin:' header will be set by browsers when requesting
		# fonts, etc. Tell the browser to allow such requests only on
		# HTTPS, from any subdomain of djangoproject.com.
		add_header "Access-Control-Allow-Origin" $sanitized_origin;
		add_header "Vary" "Origin";
	}
}

It seems that the response you're receiving have the wrong Access-Control-Allow-Origin header set on them. Unfortunately, your first screenshot doesn't show the value (you have to scroll a little further up in the response headers). Can you report on the value of the Access-Control-Allow-Origin response header on the response that is blocked by CORS?

sarahboyce · 2025-01-22T09:04:23Z

Can you report on the value of the Access-Control-Allow-Origin response header on the response that is blocked by CORS?

https://docs.djangoproject.com/

sarahboyce · 2025-01-22T09:25:16Z

Cleared my cache on firefox, desktop this morning and the error is gone and icons load. I know have the correct Access-Control-Allow-Origin 🥳

Clearing the cache isn't working on mobile, I don't have access to errors to see what is going on there 🤔

sarahboyce · 2025-01-22T09:34:10Z

Ah there's a "filter" on clearing data on mobile to only do the last 24 hours 🤦
I have now "blitzed" the cache and it is working on mobile. I'm not sure what happened but I imagine it was a temporary issue and if not, can always reopen 👍

bmispelon · 2025-01-23T09:08:28Z

I think I managed to reproduce the issue consistently with these steps (using Firefox on desktop):

Clear cache
Visit www.djangoproject.com
Visit https://docs.djangoproject.com/en/5.1/intro/install/ (or any page that contains icons)

When doing that, the icon that should be in the green box "Always refer to the documentation that corresponds to the version of Django you’re using!" is missing and replaced by a square box with 4 letters.

My best understanding of the bug is that the browser is caching the font alongside the Access-Control-Allow-Origin, then refusing to reuse the font on a different domain than the original response. If that's correct I'm not sure whether that's a browser bug, or a misconfiguration on our end 🤔

bmispelon · 2025-01-23T09:14:26Z

I wonder if this might be the issue we're seeing: https://stackoverflow.com/questions/44800431/caching-effect-on-cors-no-access-control-allow-origin-header-is-present-on-th

If so, the fix suggested in the top answer is to tweak the Vary header (in the server config):
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method

I'll try that config change later today and see if that helps.

adamzap · 2025-01-23T15:45:23Z

@bmispelon Good find! Are you getting this on the document response when you go to https://www.djangoproject.com/ ?

Does that seem correct?

sarahboyce · 2025-01-24T09:54:12Z

I think I managed to reproduce the issue consistently with these steps (using Firefox on desktop):
1. Clear cache

2. Visit [www.djangoproject.com](http://www.djangoproject.com)

3. Visit https://docs.djangoproject.com/en/5.1/intro/install/ (or any page that contains icons)

🎉 yes, this is it.
My icons broke again for me though being on a mixture of docs.djangoproject.com and www.djangoproject.com

bmispelon · 2025-01-24T13:12:37Z

The fix I did with the headers appears to be live (I even cleared the fastly cache), but unfortunately it doesn't seem to have fixed anything 😿

adamzap · 2025-01-24T20:19:53Z

I'm not sure if I'm reading the docs (1, 2) correctly, but I'm trying to understand why this header is helpful on the site at all. Is anyone sure?

apollo13 · 2025-02-02T21:10:19Z

@bmispelon The browser is caching the response. ~~Can you try removing the etag (etag off; in that section is probably enough) and clear the fastly cache again?~~ See comment below.

EDIT:// Though even the expires might (?) exhibit the same problem mhm. I wonder if there is actually a fix for that. Anyways the bug your are running into is probably something along the lines of https://issues.chromium.org/issues/41470498

apollo13 · 2025-02-02T21:21:25Z

@bmispelon Got a better idea, can you try setting add_header "Access-Control-Allow-Origin" $sanitized_origin always; (note the added always at the end) and then clear the fastly cache, then I can look into my browser logs again.

apollo13 · 2025-02-02T21:27:19Z

@adamzap

I'm not sure if I'm reading the docs (1, 2) correctly, but I'm trying to understand why this header is helpful on the site at all. Is anyone sure?

It is required to load the woff files at all which are subject to CORS. But simply allowing * might be okay (I don't remember why we decided against it -- maybe the fonts are licensed and we are required to ensure that they can only be loaded from our pages).

apollo13 · 2025-02-07T15:42:27Z

I have thought more about this. Even if we were to get the current approach working the browser would probably still recheck the font files when switching between docs & www. As such I recommend settings Access-Control-Allow-Origin to * which will effectively fix this and also prevent the revalidations.

adamzap · 2025-02-07T15:45:59Z

@apollo13 For what it's worth, this makes sense to me as well. I don't think we need to lock things down with this header.

adamzap · 2025-02-24T23:23:41Z

This should not have been closed by #1949...or was it actually fixed at the ops level?

adamzap · 2025-03-04T23:52:54Z

I'm not getting Roboto consistently on the production site, probably because of this issue. I mentioned in #1949 that we should address this issue before merging/deploying self-hosted fonts.

Let me know if there's anything I can do to help address this!

laymonage · 2025-03-05T11:21:12Z

Same here. I see the font-face declarations for Roboto are missing in place where I'd expect them to be:

I'm not sure if it's the same issue, but it does seem to be caching/CDN related because the code is already there:

djangoproject.com/djangoproject/scss/_utils.scss

Lines 46 to 95 in 2b81dae

    
           // @font-face declarations 
        
           @font-face { 
        
               font-family: 'Roboto'; 
        
               src: url('#{$font-path}/Roboto-Regular.woff2') format('woff2'); 
        
               font-weight: 400; 
        
               font-style: normal; 
        
           } 
        
           @font-face { 
        
               font-family: 'Roboto'; 
        
               src: url('#{$font-path}/Roboto-Italic.woff2') format('woff2'); 
        
               font-weight: 400; 
        
               font-style: italic; 
        
           } 
        
           @font-face { 
        
               font-family: 'Roboto'; 
        
               src: url('#{$font-path}/Roboto-Bold.woff2') format('woff2'); 
        
               font-weight: 700; 
        
               font-style: normal; 
        
           } 
        
           @font-face { 
        
               font-family: 'Roboto'; 
        
               src: url('#{$font-path}/Roboto-BoldItalic.woff2') format('woff2'); 
        
               font-weight: 700; 
        
               font-style: italic; 
        
           } 
        
           @font-face { 
        
               font-family: 'Roboto'; 
        
               src: url('#{$font-path}/Roboto-Light.woff2') format('woff2'); 
        
               font-weight: 300; 
        
               font-style: normal; 
        
           } 
        
           @font-face { 
        
               font-family: 'Fira Mono'; 
        
               src: url('#{$font-path}/FiraMono-Regular.woff2') format('woff2'); 
        
               font-weight: 400; 
        
               font-style: normal; 
        
           } 
        
           @font-face { 
        
               font-family: 'Fira Mono'; 
        
               src: url('#{$font-path}/FiraMono-Bold.woff2') format('woff2'); 
        
               font-weight: 700; 
        
               font-style: normal; 
        
           }

Switching browsers and using incognito did not work.

bmispelon · 2025-03-05T14:57:58Z

I'm not sure if it's the same issue, but it does seem to be caching/CDN related because the code is already there:

This is super weird and I don't really understand how it's possible. What seems to have happened is that we served the page with the new version of base.html (the one where the <link>s have been removed) but the old version of output.css (you can see the hash is 4bab36a7ad8a when it should be 7ae60ccd2c72). And that page with now broken fonts managed to be cached by Fastly. I wonder if it's the same issue that causes a bunch of errors on Sentry when we deploy changes that move/delete a static file (we're tracking this internally on the ops team but haven't made progress) 🤔

In any case, this should resolve itself once the cache clears. You can get get a non-cached version of the page by appending ?some_random_string to the end of the URL and you should see the correct font there.

So that was a real issue, but separate from the original one 😁

apollo13 · 2025-03-05T15:02:58Z

What seems to have happened is that we served the page with the new version of base.html (the one where the s have been removed) but the old version of output.css (you can see the hash is 4bab36a7ad8a when it should be 7ae60ccd2c72).

@bmispelon I can imagine that happening if collectstatic isn't executed before the server starts in which case the staticfiles manifest might still have old data?

tobiasmcnulty · 2025-03-06T16:09:12Z

@bmispelon I can imagine that happening if collectstatic isn't executed before the server starts in which case the staticfiles manifest might still have old data?

@apollo13 I think you are onto something. We have a WIP PR on the private deployment repo to re-organize how deploy commands are run. I deployed from this branch last night.

I wonder if someone could check to see if the bug is currently reproducible?

adamzap · 2025-03-06T16:12:18Z

@tobiasmcnulty For what it's worth, font and icon assets are fixed for me!

laymonage · 2025-03-06T16:40:22Z

I can confirm that the font loads properly for me too. (And the icons for that matter, but I don’t remember whether I had that issue or not.)

apollo13 · 2025-03-06T17:43:20Z

@tobiasmcnulty access-control-allow-origin https://www.djangoproject.com/ in the response headers is still there, so icons will still fail to load when switching domains (see #1881 (comment)).

tobiasmcnulty · 2025-03-07T01:32:52Z

@apollo13 I see, I can indeed reproduce that if I step away for a bit and come back. A force reload fixes it.

We can change the header as you suggested, or even move away from the static.dp.com domain in favor of building the assets into the image and serving them with gunicorn from www.dp.com/static/, docs.dp.com/static/, etc. Everything is behind Fastly now, so the separate static.dp.com domain and build step feel like unnecessary complexity. What do you think?

tobiasmcnulty · 2025-03-07T02:01:35Z

I changed the header so we can see if that fixes it:

❯ curl -I https://static.djangoproject.com/fonts/Roboto-Light.4b97d1da126a.woff2 2>/dev/null | grep access
access-control-allow-origin: *

Either way, I'd still be grateful for any feedback on the /static/ approach (i.e., sunsetting static.dp.com).

adamzap · 2025-03-07T02:37:13Z

If the separate domain isn't benefitting the site, I don't see the point in keeping it. I'm not on the ops team though, so I don't know all the details.

apollo13 · 2025-03-07T05:30:03Z

Getting rid of the static subdomain makes sense if www. and docs. don't share a Cache in the browser because then you'd download the font etc twice anyways. If they share one (which I somewhat suspect) then the subdomain is good (will check later whether they share the cache entry or not).

…

On Fri, Mar 7, 2025, at 02:33, Tobias McNulty wrote: @apollo13 <https://github.com/apollo13> I see, I can indeed reproduce that if I step away for a bit and come back. A force reload fixes it. We can change the header as you suggested, or even move away from the static.dp.com domain in favor of building the assets into the image and serving them with gunicorn. Everything is behind Fastly now, so the separate domain and build step feel like unnecessary complexity. What do you think? — Reply to this email directly, view it on GitHub <#1881 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAT5C4ZMGLDEDZF4MMU3Z32TDZNTAVCNFSM6AAAAABVOZKMVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBVGMYTCNRTGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***> tobiasmcnulty*tobiasmcnulty* left a comment (django/djangoproject.com#1881) <#1881 (comment)> @apollo13 <https://github.com/apollo13> I see, I can indeed reproduce that if I step away for a bit and come back. A force reload fixes it. We can change the header as you suggested, or even move away from the static.dp.com domain in favor of building the assets into the image and serving them with gunicorn. Everything is behind Fastly now, so the separate domain and build step feel like unnecessary complexity. What do you think? — Reply to this email directly, view it on GitHub <#1881 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAT5C4ZMGLDEDZF4MMU3Z32TDZNTAVCNFSM6AAAAABVOZKMVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBVGMYTCNRTGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

tobiasmcnulty · 2025-03-07T13:01:11Z

@apollo13 Good point, yes, they do share the browser cache (wasn't that the issue?). In fact, I still had a stray font in my browser cache with the old header this morning, and it didn't load for me until after a force-refresh.

@adamzap @bmispelon Perhaps we should also change $font-path or add a query string to each font path to force browsers to reload the fonts now that the header is changed? They are set to cache forever, so until the path changes or they are force-reloaded, I think browsers will happily continue using their local copy.

❯ curl -I https://static.djangoproject.com/fonts/Roboto-Light.4b97d1da126a.woff2 2>/dev/null | grep cache-control
cache-control: max-age=315360000

apollo13 · 2025-03-07T13:10:49Z

@apollo13 Good point, yes, they do share the browser cache (wasn't that the issue?). In fact, I still had a stray font in my browser cache with the old header this morning, and it didn't load for me until after a force-refresh.

Ah yes, I have lost track of what is cached where now :D

adamzap · 2025-03-08T17:30:18Z

@tobiasmcnulty That's a good idea. I can think of two approaches that should both create a cache invalidation for users and maybe even increase consistency in our static assets:

Change $font-path from ../fonts to ../font and rename the directory. This would be more consistent with /static/img/
Rename the font files to be all lowercase.

We could also just add ?v2 at the end of the font asset filenames, but that seems a bit more esoteric to me. I'm not strongly against it though.

@bmispelon Any thoughts? I'd be happy to open a PR for this once we decide on an approach. I may lean toward doing both of the renaming changes above, but I defer to you.

bmispelon · 2025-03-08T17:54:19Z

@adamzap All these should have the same cache-busting effect indeed. I'd say option 1 is marginally better, since it requires the least amount of change I believe.

Refs django#1881

Refs #1881

bmispelon · 2025-03-08T21:15:51Z

I've deployed the changes suggested by Tobias in #1881 (comment) (thanks to a fast response by Adam).

As far as I can tell, this issue is now completely fixed, no?

adamzap · 2025-03-08T22:48:42Z

Looks good to me so far!

sarahboyce changed the title ~~Icons on mobile fail to load~~ Icons fail to load Jan 21, 2025

This was referenced Jan 21, 2025

RSS icon broken #1887

Closed

Removed competing font-awesome link. #1888

Closed

sarahboyce closed this as completed Jan 22, 2025

bmispelon reopened this Jan 23, 2025

bmispelon closed this as completed Jan 23, 2025

bmispelon reopened this Jan 24, 2025

adamzap mentioned this issue Feb 13, 2025

Self-host "Roboto" font assets #1949

Merged

pauloxnet closed this as completed in #1949 Feb 24, 2025

adamzap reopened this Feb 24, 2025

adamzap added a commit to adamzap/djangoproject.com that referenced this issue Mar 8, 2025

Rename font asset dir to invalidate browser caches

ea59664

Refs django#1881

adamzap added a commit to adamzap/djangoproject.com that referenced this issue Mar 8, 2025

Rename font asset dir to invalidate browser caches

59560f3

Refs django#1881

adamzap mentioned this issue Mar 8, 2025

Rename font asset dir to invalidate browser caches #1977

Merged

bmispelon pushed a commit that referenced this issue Mar 8, 2025

Rename font asset dir to invalidate browser caches

e6a620b

Refs #1881

Icons fail to load #1881

Icons fail to load #1881

Comments

sarahboyce commented Jan 19, 2025 • edited Loading

sarahboyce commented Jan 20, 2025

pauloxnet commented Jan 20, 2025 • edited Loading

Chrome 132

Firefox 134

sarahboyce commented Jan 20, 2025

adamzap commented Jan 20, 2025

sarahboyce commented Jan 20, 2025

nessita commented Jan 20, 2025

sarahboyce commented Jan 20, 2025

adamzap commented Jan 20, 2025

adamzap commented Jan 20, 2025

sarahboyce commented Jan 21, 2025

bmispelon commented Jan 21, 2025

sarahboyce commented Jan 22, 2025

sarahboyce commented Jan 22, 2025

sarahboyce commented Jan 22, 2025

bmispelon commented Jan 23, 2025

bmispelon commented Jan 23, 2025

adamzap commented Jan 23, 2025

sarahboyce commented Jan 24, 2025

bmispelon commented Jan 24, 2025

adamzap commented Jan 24, 2025

apollo13 commented Feb 2, 2025 • edited Loading

apollo13 commented Feb 2, 2025

apollo13 commented Feb 2, 2025

apollo13 commented Feb 7, 2025

adamzap commented Feb 7, 2025

adamzap commented Feb 24, 2025

adamzap commented Mar 4, 2025

laymonage commented Mar 5, 2025

bmispelon commented Mar 5, 2025

apollo13 commented Mar 5, 2025

tobiasmcnulty commented Mar 6, 2025

adamzap commented Mar 6, 2025

laymonage commented Mar 6, 2025

apollo13 commented Mar 6, 2025

tobiasmcnulty commented Mar 7, 2025 • edited Loading

tobiasmcnulty commented Mar 7, 2025

adamzap commented Mar 7, 2025

apollo13 commented Mar 7, 2025 via email

tobiasmcnulty commented Mar 7, 2025

apollo13 commented Mar 7, 2025

adamzap commented Mar 8, 2025

bmispelon commented Mar 8, 2025

bmispelon commented Mar 8, 2025

adamzap commented Mar 8, 2025

sarahboyce commented Jan 19, 2025 •

edited

Loading

pauloxnet commented Jan 20, 2025 •

edited

Loading

apollo13 commented Feb 2, 2025 •

edited

Loading

tobiasmcnulty commented Mar 7, 2025 •

edited

Loading