Icons fail to load

[sarahboyce]

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:

[sarahboyce]

e51e74b is possibly related (@adamzap)

[pauloxnet]

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]

Android 14, Chrome 132

[adamzap]

@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]

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

[nessita]

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]

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

[adamzap]

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]

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]

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]

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]

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]

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]

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]

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

1. Clear cache
2. Visit www.djangoproject.com
3. 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]

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]

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

Does that seem correct?

[sarahboyce]

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]

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]

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]

@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]

@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]

@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]

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]

@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.