Problem with HTML file On Amazon S3 (18)
I have been having a problem with Amazon S3 currently. Every time my assistant edits the landing page and uploads the HTML file, the old material is still being presented on the landing page. So he has to either create a new folder or change the name of the HTML file. For all Amazon S3 users, do you guys have the problem? If yes, how do you solve the problem so the old material won't be presented anymore?
Are you accessing the file directly from S3 or from the final domain?
If you are accessing the file from S3 there shouldn't be any cache issues. But when you access it using the final domain, which goes through Cloudfront, then you'll have to invalidate the file on Cloudfront to be able to access the new version.
The file is being downloaded from S3 and edited. After that, the file is uploaded into the same folder, and it overwrites the previous file because the edited HTML file has the same file name as the previous one.
You can't easily "rewrite" the HTML file once it's uploaded. You need to rename it or create a new folder and upload it.
I agree with @platinum. It looks like the final domain is connected to a CloudFront distribution and you did not invalidate the cache
When you add new files to S3, they do not replace the cached versions in CloudFront, as CloudFront does not connect to S3 until 1) the file expiration date 2) you erase the cache manually.
To do this, you need to invalidate the file(s) in CloudFront
https://docs.aws.amazon.com/AmazonCl...ation_Requests
If you want to have this done automatically, and you have someone with a tech background to help, please have a look at the following article. It uses an Amazon Lamda function to clear the CloudFront cache. When a document is updated S3, AWS automatically triggers an S3 event, which you can bind to, in order to invalidate the cache. They are a few tweaks to do to the function in the article to improve it (notably log or give feedback regarding the update process). I have not investigated it yet deeply, as I am waiting for my dev to finish another Lambda function, but I will do next week.
https://kupczynski.info/2019/01/09/i...lambda-s3.html
Originally Posted by robbie28
Originally Posted by jeremie
Or. Much easier than all that. Just set the TTL to 0 in cloud front and leave it there.
Sent from my iPhone using STM Forums
Good idea. I will check it out.
Originally Posted by jaybot
By using TTL 0, CloudFront has to send a request to the S3 origin for every request that hit the CloudFront page to verify that the page has not been updated, so that defeats the purpose of using CloudFront to cache static assets, and you increase the time to deliver the page for each request.
Originally Posted by jeremie
But when testing landing pages and trying to get everything setup and working, setting it to TTL 0 until you are done is much easier and more efficient than invalidating the files every time.
Once you get everything up and running, then set the TTL back to whatever the default is
Originally Posted by jaybot
A quick update on this as I was recently looking more in depth at AWR CloudFront pricing model.
https://aws.amazon.com/cloudfront/pricing/
I realized that invalidations are paid after the first 1000.
So if you are doing lots of changes while doing dev, @jaybot recommendation to set the TTL to 0 during dev might save you a bit.
Originally Posted by jaybot
But when testing landing pages and trying to get everything setup and working, setting it to TTL 0 until you are done is much easier and more efficient than invalidating the files every time.
Once you get everything up and running, then set the TTL back to whatever the default is
https://docs.aws.amazon.com/AmazonCl...xpiration.html
Originally Posted by jeremie
Originally Posted by iwanttofly
Originally Posted by iwanttofly
Just set them all to 0. Doesn't matter.
Just make sure you put them back when you're done.
Home > Technical & Creative Skills > Programming, Servers & Scripts