We are not get the updated data in live after Invalidating urls /redeploying in the vercel? - vercel

After invalidating the urls in vercel , We are unable to see the changes in Live But we can see the changes in Test url? (We use Redeployment for Invalidation)

Related

Cloudfront caching react website pages despite using file versioning

So to explain a problem I have a static website hosted on s3 and CloudFront as the CDN. I have used create-react-app(CRA) to create the react package for my website. CRA by default does versioning of webpack build files and the versions are visible in the s3 bucket as well.
Still when I do a deployment, the latest changes don't come up(I have waited even a day hoping it would come). I am not sure what is causing this issue. Can anyone please help.
I have added the screenshots of my cloudfront behaviour tab and the s3 bucket files having build versions.
Ps, If it is the case of browser cache how can I disable it so that my clients always see the most latest version of my website.
Hi you have to invalidate cache in the distribution settings tab. I ideally invalidate all cache by passing /* or you can also specify folder or file to clear cacheing.
example: /index.html
Even in your CI/CD pools line you can ask deploy agent to invalidate cache by passing distribution ID and path

After deploy taking time to reflect changes

I have a project which is built-in ReactJs. and I am using s3 and CloudFront for deployment.
I am facing an issue whenever I deploy code after deployment it takes too much time to reflect changes. sometimes I have to manually clear browser cookies for the latest changes. Do I need to configure S3 or CloudFront settings?
Follow this steps:
Go to cloudfront :
Do invalidation of objects
Create entry /*
Reference : https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serving-outdated-content-s3/

Host Blazor WASM in S3 bucket

I am trying to host my Blazor WASM application on my S3 bucket under a sub path, but I can't really get it to work like I would expect it to.
In order to get it to work, I had to make some changes which I would've preferred not needing to make, especially since they break the application on my development build, so I always have to change between the 2 when I publish / want to develop
In my application I have 2 pages, lets say page1 and page2. On application startup, I want to see page 1. this page has the #page "/" on top. The other page has #page ="/page2". These same paths are then found in my NavMenu.razor.
Now locally I don't care for sub paths, so I'm fine with the application being hosted at localhost:port/ which would go to page 1, and localhost:port/page2 which would go to page 2. In order to get it working in my S3 bucket however, where my application is hosted under s3Url/subpath/{published files}, I had to make some changes: in my index.html I put the
I find myself unable to make all of these changes through appsettings or environment, which makes it time consuming, and error prone to accidentally make errors and push the wrong settings to my s3 bucket when i publish.
Is there any way to handle a sub path better? In the documentation I found this the following article where they talk about this exact issue, and they say it can be fixed by running it locally using this command:
dotnet run --pathbase=/{RELATIVE URL PATH (no trailing slash)}
but even if I do that, since I had to edit all page names and nav links it still doesn't work.
I feel like there must be a better way for me to handle this, so that it works on both development and also on publish, without having to make additional code changes whenever I publish, and then undoing them again when I want to develop locally.

Akamai CDN Issue with URL Query Parameter

I am working on a client project, where the AKAMAI CDN has configured. They got Amazon S3 for hosting.
Problem:
I've committed the code in branch and could see the changes deployed on server in a codebase
Now I am trying to hit server URL in browser and trying to verify my code change
I couldn't see the UI change as per
I observer the CSS file URL is coming with query parameter (i.e.: server.com/css/filename.css??browserId=other&themeId=AbcTheme_WAR_abctheme&?t=125786954258&languageId=en_US&b=8569&t=1259648753695)
Now I am opening same URL in browser but now removing url query parameters from the file
This time I could see my changes in the same file
Questions:
Is this an issue related to CDN?
Is the CDN managing different versions of the same file to be served?
If so my changes should be merged into the latest file pointing to a webpage, which has url query parameters.
I know CDN will take time to refresh the pages but I am trying to verify my changes after 48 hours of the deployment.
Any help would be appreciated.
Thanks.

Force re-download of file cached with cache.appcache

My question is similar to this one, but the solutions provided haven't helped me: Force applicationCache to reload cached files
Here's the run down. I currently have a sencha touch application hosted on S3, and there's a problem which requires an update to the index.html file.
In order to enable offline access to the app, I've cached index.html in cache.appcache. Below is my cache.appcache file:
CACHE MANIFEST
# 127476e50461cf415c27fb33d81914faab1fc687
index.html
# 364c8e0f0cc7c9922d0019d083b4abba7d519e1c
resources/images/ajax-loader.gif
# 4028c1082f32387af25e2399aae7173ed0a51cf4
resources/images/cloud_download.png
# 40454710d633ca15b65d891d3842d3ef8b2136bf
resources/images/delete1.png
# 62c6a1ec578fa7d1d7a3117c2a84c5195c33ddb8
resources/images/loading.png
# ad85882c6285881966307da8da97ff597de9a486
resources/images/loadingbg.gif
# d2abb7549cd282c1e3fec6e9249d1e51ad5ec75d
resources/images/logo.png
FALLBACK:
NETWORK:
*
In hindsight, to enable offline access I should have probably left index.html as a non-cached network file with a fallback to some 'offline.html' file, but the app's been deployed for a while, and I need to make a change to index.html, and I just can't get the file to update, not even on my local machine by clearing the cache, and not by using private browsing as per the link above. I need to be able to change the file without the user having to do anything to receive the changes.
Here's what I've tried:
1) I removed index.html from the cache manifest and uploaded it. When I did that, and reloaded, the browser picked up the updated cache manifest and downloaded the files:
Application Cache Progress event (0 of 6) http://m.example.com/resources/images/loading.png (index):1
Application Cache Progress event (1 of 6) http://m.example.com/resources/images/ajax-loader.gif (index):1
Application Cache Progress event (2 of 6) http://m.example.com/resources/images/cloud_download.png (index):1
Application Cache Progress event (3 of 6) http://m.example.com/resources/images/loadingbg.gif (index):1
Application Cache Progress event (4 of 6) http://m.example.com/resources/images/delete1.png (index):1
Application Cache Progress event (5 of 6) http://m.example.com/resources/images/logo.png (index):1
Application Cache Progress event (6 of 6) http://m.example.com/ (index):1
Thankfully that means the browser isn't caching the manifest file, but unfortunately, even though it downloaded the index, the file didn't update. I've confirmed the file has been properly uploaded to the s3 bucket, and if I download the file the changes are there, but even after reloading the browser, clearing the browser cache multiple times, viewing the source shows the old index.html file. Note if I go to http://m.example.com/?bla, it works, so I know s3 is serving the correct file (although I haven't ruled out an s3 request cache), but http://m.example.com/ is still broken.
I'm guessing that, although the appcache is redownloading the file, at the browser level it's still cached, so appcache is just downloading the browser's cached version, although clearing the browser cache doesn't fix the issue.
2) I never set any expires headers on the file in s3 so not sure if s3 sets really long expiration headers by default, but I've tried adding Expires: -1 to index.html but doesn't help.
3) I've also tried uploading a new file called index2.html, and changing the index document in the s3 bucket to index2.html, but still I'm getting the old copy.
Not only do I need to get this working on my dev machine, but I also need to fix the issue on existing user's browsers, ideally without them having to do anything. I'm starting to think my only option is changing the app url, which I'd really rather not do. The index page seems so hard wired into the browser I'm not sure if even pointing m.example.com to a new ip address would help. Anyone have any ideas how I could solve this?
Update: I tried looking in the network tab in the chrome console while at the same time pushing up a new cache manifest and reloading the page. Unfortunately cache manifest requests don't seem to show in the network tab even if they're being re-downloaded.
Ok so after a bit more searching I discovered some idiosyncrasies in appcache, like the fact that whatever page includes your cache manifest, is auto cached by default regardless of your settings. I would have thought that, if the manifest was updated, the browser would at least re-download index.html, but it appears not. I used the solution found in the link below which indicates a workaround where you attach your manifest to another page which you reference in your source page via iframe, therefore allowing index.html to be not cached again.
My HTML5 Application Cache Manifest is caching everything
After doing that, to avoid future caching issues I made a duplicate page at 'offline.html' and made a failover pointing index.html to offline.html. So basically index.html is now never cached and isn't going to leave me stranded with an unusable domain, and when offline it will redirect to the offline page which can be happily cached for offline access. Phew!