-
Posts
-
Hello,
There are display issue with some pages in the web site because some files from the CDN are not being loaded. The error shown in the ‘inspect element’ browser dev tools shows:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://(removed) (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
The box to add the header is checked:
Add CORS header
Add CORS headers to allow cross-domain assets usage.
on the CDN settings page.Please explain why the CORS header is not being added, and how to correct this issue.
Thank you.
Hello,
Thank you for reaching out and I am happy to assist you with this.
Can you please share more information about the issue you are experiencing?
1. Which CDN Provider you are using?
2. Which files are affected by the CORS problem?
3. Is your website on Apache, Nginx, or Nginx+Apache?
4. Can you please share your website URL?Thanks!
1. Which CDN Provider you are using?
FTP/Local
2. Which files are affected by the CORS problem?
web fonts (.woff, .ttf)
3. Is your website on Apache, Nginx, or Nginx+Apache?
Nginx+Apache
4. Can you please share your website URL?
Please do not publish URL, remove before posting:
removedNote that I do see in the .htaccess file where W3TC is adding the Access-Control-Allow-Origin header, but the browser still says it is missing. It used * for the URL, so I changed that to the actual CDN URL, but the browser still said the header is missing. I have also edited the HTTPD and NGINX conf files, and using curl -i does show the added headers, but the browser still says they are missing. So no matter how the headers are added, the browser does not see them.
Also, from what I can see the problem is only with font files, not other items (.css, .js, etc.) that are loaded as expected from the CDN. I have verified that the font files do exist in the correct locations in the CDN site.
Thank you.
One other thing that is not working is the Custom File List, at least not for this specific directory:
{wp_content_dir}/fonts/*
It does not matter if it is specified like that, or like
/wp-content/fonts/*
or
wp-content/fonts/*
It does not include any files in that directory (and sub directories). This is a ‘non-standard’ directory which was added by another plugin, and it does have font files in the sub directories. I have checked permissions and they seem to be fine.Thank you.
Hello,
Thank you for the feedback.
There are a couple of things that you can try.
Add the following rule to the top of your .htaccess file:# FONT CORS <IfModule mod_headers.c> <FilesMatch "\.(ttf|otf|eot|woff|woff2)$"> Header set Access-Control-Allow-Origin "*" </FilesMatch> </IfModule> # END FONT CORSMake sure that NGINX Bypass Apache for static files
You can also add the rule to your ngix:location ~* \.(ttf|otf|eot|woff|woff2)$ { add_header Access-Control-Allow-Origin *; }As for your other question regarding the custom files, try adding the full path of the file and see if it uploaded, for example,
/wp-content/fonts/some-font.woffLet me know if this helps!
Thanks!
Hi Marko,
Thanks for the suggestions. I added your code to both .htaccess and nginx conf files and it made no difference. The .htacess file already had the W3TC sections with 3 FilesMatch areas, and all of the font file types are already listed in those areas. I had previously tried adding the Header Set code to those 3 areas but it did not change anything (the browser still shows the CORS header missing error for the font files).
You said “Make sure that NGINX Bypass Apache for static files”. I am not exactly sure how to do that, but the following seems to indicate that it is:
curl -i https://(removed)/myfont.ttf
HTTP/2 404
server: nginx
date: Tue, 07 Dec 2021 20:49:40 GMT
content-type: text/html
content-length: 146
vary: Accept-EncodingThe 404 eror is expected; I just used it to get the header response for a font file request, which was ‘returned’ by nginx. One thing that may help point to the solution is that the CORS header is not shown in that response, while in a non-file request URL it does show:
curl -i https://mysite.tld (REMOVED URL)
HTTP/2 200
server: nginx
date: Tue, 07 Dec 2021 21:49:46 GMT
content-type: text/html
content-length: 543
vary: Accept-Encoding
x-accel-version: 0.01
last-modified: Wed, 23 Jun 2021 18:58:13 GMT
etag: “21f-5c5737d0b420e”
accept-ranges: bytes
vary: Accept-Encoding,User-Agent
access-control-allow-origin: https://my-cdn-url.tld (CDN URL REMOVED)As for the Custom File List, I added the full path to a font file and it did not change the number of files to upload. For whatever reason it is ignoring that particular path entirely:
/wp-content/fonts/*
or
/wp-content/fonts/life-savers/ZXu_e1UftKKabUQMgxAal8HLOh5amcDqp-RXXbs.woff
for example.
You can see the full path to the font file is valid:
curl -i https://(REMOVED)/wpbbp/wp-content/fonts/life-savers/ZXu_e1UftKKabUQMgxAal8HLOh5amcDqp-RXXbs.woff
HTTP/2 200
server: nginx
date: Tue, 07 Dec 2021 22:01:11 GMT
content-type: font/woff
content-length: 16884
last-modified: Sat, 10 Jul 2021 10:49:35 GMT
etag: “60e97b3f-41f4”
access-control-allow-origin: *
accept-ranges: bytes
Oh, but look, the CORS header IS added to the file request, so I guess in the previous file request example above it was not added because it was a 404 error response, not a font file response. OK, so now we do see that the CORS header is in fact being added, but the browser STILL says it is missing for all of the CDN font files. Now what?!Thank you.
Hi Marko,
You’re probably busy with the holidays, but I wanted to update you on the issues.
1. CORS header issue is resolved
The problem was that the CORS header needed to be added to the ‘resource’ server, not the ‘origin’ server. This may be obvious to someone who has experience with CDN and CORS, but to most WordPress users who run across CORS because they installed the W3TC plugin, it would save a LOT of time and aggravation if you would let them know this simple fact, especially since ‘Add CORS header’ is an option in the settings.
To clarify, if a 3rd party CDN is used they would have the CORS header added in their servers’ settings, but for someone who is using the self hosted/FTP option they need to know that the CORS header has to be added to the CDN servers’ settings.2. Custom File List – there appears to be a bug in the coding which translates the placeholder {wp_content_dir}. I have used the Custom File List on 2 different sites, and the problem is only on a site where WordPress is installed into a sub-directory. Not only does the placeholder {wp_content_dir} not work, but also the sub-directory has to be included in the real path. In other words, instead of
/wp-content/etc.
use
/sub-directory/wp-content/etc.
FYI the other placeholders seem to work fine on both sites.Thank you.
- The topic ‘CORS header not added’ is closed to new replies.
