- Le plus récent
- Le plus de votes
- La plupart des commentaires
You need to invalidate your cache...that's probably the issue..check out the invalidation tab in cloudfront... distribution settings. It takes 15 or so minutes per invalidation.
Also, when testing, be sure you are getting a HIT from Cloudfront. Because it's a CDN, even after the first try after getting a HIT, you could receive a miss, especially when the site is first getting hit. Think of 1000s of servers across multiple regions that need to get the content on their first request and cache it...
Do you have a single behavior?
Can you share all of your Default Cache Behavior Settings settings?
Yes, single behavior set up following the https://console.aws.amazon.com/cloudfront/home?region=us-west-2#create-distribution:
page. Kept most of the options default, except picked Redirect HTTP to HTTPS
. Later, as noted, set Object Caching
to Customize
.
Path Pattern Default (*)
Origin or Origin Group my-s3-bucket
Viewer Protocol Policy Redirect HTTP to HTTPS
Allowed HTTP Methods GET, HEAD
Field-level Encryption Config blank
Cached HTTP Methods GET, HEAD (Cached by default)
Cache Based on Selected Request Headers None (Improves Caching)
Object Caching Customize
Minimum TTL 0
Maximum TTL 31536000
Default TTL 31536000
Forward Cookies None (Improves Caching)
Query String Forwarding and Caching None (Improves Caching)
Smooth Streaming No
Restrict Viewer Access No
Compress Objects Automatically No
Lambda Function Associations blank
I'm noticing the cache-control header missing on some files from the root of another S3 bucket I set up with CloudFront. I set the metadata in bulk selecting all the files in the S3 bucket, and I see that each file has the cache-control present in its metadata. But, somehow, 2 files out of about 20 get delivered to the browser without the cache-control header via the CloudFront link - the others work fine. Makes no sense ... I'm thinking I might've set the S3 metadata after initiating the CloudFront distribution - so, possibly, some files got into the CDN cache before the tags were recorded in S3, and some after, but it's a far shot explaining the misbehavior. Not sure if there is a way to "re-push" the files into the CDN at this point to test out if they all get recorded with the proper tags.
After a couple of days, CloudFront displays proper cache-control headers on all the S3 source files. Got to be related to the lag how this feature is handled, considering the internal CF caching. So, it looks like the S3 metadata must be set before the CF distribution is created, or the files must be invalidated explicitly in the CF. I assumed, the caching in CF would apply to the content of the files only. Looks like it applies to more than that. If this is documented somewhere - my bad missing. Although, it certainly makes sense if CF behaves as a fully independent layer that reaches back to the origin for anything only if its internal caching is empty.
Edited by: svdev on Feb 25, 2019 12:52 AM
Contenus pertinents
- demandé il y a 3 mois
- demandé il y a un an
- demandé il y a 6 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 8 mois
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an