cache control header not present

Hello @megunticook

Thank you for reaching out and I am happy to assist you with this. In some cases, the setup guide may not recognize specific modules, however, this does not mean that the headers are not present. I am unable to see the staging version of the website, so can you please check the HTML, CSS, JS, and image files if they have the cache-control header?

I’ve checked baldmountainbotanicals.com and the header is present there.

Thanks!

Thanks, I’m in the middle of setting up a CloudFront distribution now so I’m going to get that set up first then return to this issue. Thanks for you suggestions. Will report back.

I got a CloudFront CDN all set up in my staging environment working fine, however now I’m working on the production version and have an issue where browser is giving a 404 error on all the gzip files. The files appear to be in the CDN but the gzip files are not on the EC2 instance. Also noticed those gzips all loaded fine when viewing the CNAME URL (cdn.baldmountainbotanicals.com) but not the regular url without the prefix. I’m editing my Windows .hosts file to test the new setup by redirecting my browser that new server without actually changing my public DNS. Don’t suppose that would matter with the .gzip issue, would it?

In any case let me know if you have any ideas. Thanks.

I think I’m pretty close here but in both my setups there’s an issue with the browser getting either a 404 or 403 error on the files that were gzipped–see screenshot below.

One example is this url that’s returning a 404: https://cdn.baldmountainbotanicals.com/wp-content/cache/minify/82b6c.default.include.286b85.css?x52735. Going to go look and see if that file is actually there in the S3 bucket or not. But why is this just happening to those files that were gzipped before?

Back for another update, I now have the production site configured with CloudFront and S3. Have a few little wrinkles to iron out. One is that peksy CORS issue with the font files that the browser won’t load. I was able to resolve that on staging site but for the life of me I cannot get it right on the production site. I’ve been over all the settings for the distribution, the s3 bucket, and W3TC many times and something just is not quite right.

Can you tell looking at it? Evidently I need the “Access-Control-Allow-Origin” header on those files but can’t seem to get there. Something must be misconfigured somewhere but for the life of me I cannot find it. Any help appreciated. https://baldmountainbotanicals.com.

• This reply was modified 2 years ago by Megunticook.

deleted post

• This reply was modified 2 years ago by Megunticook.

Seem to have resolved the CORS issue finally by invalidating those font files in the CloudFront distribution and forcing CF to go back to the S3 bucket instead of using a cached version of those files.

Still odd though, when I look at the header for the file on the web server I see the Access Control Header but when I look at the header for the same file on the CDN I don’t see the Access-Control-Allow-Origin header.

Here’s one of the font files (https://baldmountainbotanicals.com/wp-content/themes/kadence/assets/fonts/star.woff2?gmcsp2) on server:

HTTP/2 200

date: Fri, 03 Mar 2023 13:44:28 GMT

content-type: font/woff2

content-length: 532

server: nginx/1.22.1

last-modified: Fri, 03 Mar 2023 03:36:45 GMT

etag: "64016b4d-214"

access-control-allow-origin: *

accept-ranges: bytes

And here it is on the CDN (https://cdn.baldmountainbotanicals.com/wp-content/themes/kadence/assets/fonts/star.woff2?gmcsp2):

HTTP/2
200
content-type: font/woff2
content-length: 532
date: Fri, 03 Mar 2023 13:58:16 GMT
last-modified: Fri, 03 Mar 2023 13:48:01 GMT
etag: "608479835951195a7e28035f47663dad"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 0f538ee832e1105649039b38ce89e882.cloudfront.net (CloudFront)
x-amz-cf-pop: FRA2-C1
x-amz-cf-id: bnKhsl6-FT8bZlcZsN3zQo7YNBXC64P3MQru806Axu4G7eglRJa57A==
age: 381

As you can see, the Access-Control-Allow-Origins header is gone in the CDN version. Why is that? And shouldn’t it still be causing a CORS issue?

My S3 bucket has this CORS policy:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "HEAD",
            "POST",
            "PUT"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

And here’s my CloudFront configuration for the wp-content/* behavior:

Here’s for the Default (*) behavior:

In W3TC settings for CDN I have the “Add CORS header” checkbox checked.

Things seem right to you? Confused as to why that Access-Control-Allow-Origins header is missing when CloudFront serves the file. But there’s no CORS issue anymore? Strange.

Next I need to figure out why I was getting all those 404 errors on the gzipped files before I disabled gzip compression in the W3TC browser cache settings.

Hello @megunticook

I am very sorry for the late reply. I missed this topics somehow.

Yes, there is a known issue with the CORS policy for fonts when using the AWS even with the option “Add CORS header” checkbox checked. Those files need to be invalidated on the AWS.

As for the 404 on gzipped files, check if you have zlib compression enabled or any other compression outside of W3TC.

Thanks!

@vmarko Thanks, appreciate the help. Still struggling with this CORS issue (see https://baldmountainbotanicals.com/cbd-cocoa/ bottom of page for example).

I’ll check for any zlib compression enabled and circle back.

Well I tried adding the WordPress directory containing these font files to the “Rejected files” list and cleared the W3TC cache several times but problem persists. Do I need to do something on CloudFront too?

@vmarko I was able to resolve this by manually uploading those font files to my CDN. So maybe this wasn’t a CORS issue after all.

Doesn’t make sense, since I told W3TC to exclude those files from the CDN, but clearly the web page is still trying to load those files from the CDN rather than the local server.

Anyway I guess the issue is solved with this workaround but would love to know why the html on the page is still using the old CDN URL instead of the web server URL. Odd.