Akamai CDN Issue with URL Query Parameter - amazon-s3

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.

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

How to make browser download html when its content changed in s3?

I am using s3 bucket to host my web site. Whenever I release a new version of my web site, I want all clients download it from s3 instead of reading from their browser cache. I know I can set up an expire time for the object saved on s3 bucket but it is not an idea solution since users have to use the cached content for a period of time. Is there a way to force browser to download the content if they are changed in s3 bucket?
Irrespective of whether you are using s3 bucket for hosting or any other hosting server, caching can be controlled by appending hash number to file name.
For example your js file bundle name should be like bundle.7e2c49a622975ebd9b7e.js.
When you deploy it again it will change to some other hash value bundle.205199ab45963f6a62ec.js.
By doing this, browser automatically knows that, new file has arrived and should be downloaded again.
This can be easily done using any popular bundlers like grunt, gulp, webpack.
webpack example

Does my apache cache my images?

I have a folder for customer avatar upload and I set up an apache server pointing to this folder to get customer avatar images.
It seem to be a very strange symptom my system get right now as following:
I update an avatar image in the folder
I access to the image by browser, but I see it displays the old one on browser though I refresh (Ctrl+F5) many times.
After a time duration (nearly 1 min), I refresh the above url, and I got the lastest image dislayed.
Is this symptom relating to my Apache configuration? Could anyone help me to figure out which setting affects? Thank you!
First of all I am guessing that you have not enabled any of the apache caching modules. If this is the case then this behavior is due to browser's caching on the client side. You can verify this by opening the url in a browser's private session after updating the image. You can also verify by looking into apache's access.log file and check if you can see any request entry for accessing the image or not. If it's not then it is being directly served from browser's cache.

Image available on server but failed to load the given URL

I have a scenario that the image is available on the server on the said path
the whole system is running on apache with https (ssl installed and configured properly)
In my application when i generate the path and assign the same to the output (Html) it dose not show the image. Infact it says like the resource could not be loaded. But the same code works on local and many other server but on this 1 server.
Secondly if i do a view source on the same, copy the url and open the same url in browser - it opens up properly - without any issue / trouble but cannot find the same into the out generated by the app..
Any clue as why such thing should be happening??
Sorry my mistake - i realized those were tagged under folder ads and were blocked by ad block plus. Got the resolution :)

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!