gist of my diagnostic output (includes resizer config)
If I request /myBucket/myImage.jpg?w=100, then update the base image in s3, and then reload /myBucket/myImage.jpg?w=100, I still get the original image. However, any requests for new modified images get the correct updated image (e.g. /myBucket/myImage.jpg?w=333)
Based on the documentation, having s3reader2 -> checkForModifiedFiles enabled should resolve this, but it does not. I've also played with disabling s3reader2 -> cacheMetadata, but the outcome is the same.
The problem obviously does not exist if the DiskCache plugin is disabled, but that's not really an option.
Any ideas?
You are using cacheMetadata="false", which is a v4+ configuration parameter.
You are using the v3.4.3 dlls. Upgrading to v4 should resolve the issue. v3 does not have a way to fully disable metadata caching (Sliding expiration defaults to 1 hour).
related: ImageResizer S3Reader2 Plugin 404 Error after image has been uploaded
Related
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
I'm using Google Lighthouse to calculate a performance score. One of the criteria is caching static assets such as images and scripts.
I don't have control over all of these, but the ones I do have control over the cache has been set to 30 days. However, Lighthouse is still reporting these as an issue. Lighthouse does report these as having a 30d cache, but still reports as an issue.
What do I need to do to rectify this?
Please see screenshot below:
Lighthouse will warn you to serve static assets with an efficient cache policy if your score for that audit is not greater than or equal to 90. It will also list all of your static assets in the details summary (regardless of whether they pass or not).
Since you do not have control over some of your static assets, your score appears to be lower than 90, and therefore, you are still seeing your static assets that pass the audit in the details summary.
You can verify this by saving your results as a JSON file, opening it in any text editor, and searching for the section containing "uses-long-cache-ttl".
The score underneath will likely be less than 90.
You can learn more about this particular audit by visiting this link:
https://developers.google.com/web/tools/lighthouse/audits/cache-policy
I also had a 30 day cache policy and what fixed this for me was adding the public and no-cache values to the Cache-Control header.
I only figured this out as I was testing Firebase hosting vs my old host which was IIS. The IIS hosted site was passing even though it had a shorter max-age value. I checked the network developer tools in chrome and saw it had public and no cache values in my IIS web.config under the Cache-Control header but my firebase.json didn't have those values. Once added I'm passing again!
Now why this passes is a mystery to me, but see if you can add and test again.
In my case to fix the Serve static assets with an efficient cache policy error in Lighthouse, I have to increase the max-age value to 97 days:
Cache-Control: max-age=8380800
My version of Lighthouse is 5.7.0
i am curious about an issue that i am facing at the moment with Azure CDN and i don't have an answer for it. So, i have a CDN profile and endpoint configured to cache some content stored in a storage container. In the cache behavior, i am using default (ignore query strings). So i modified one file in the container, and i was able to retrieve the modified file from the container, but not from the CDN edge since the edge was returning the previous cached version of the file. So i proceed with the purge of the file in the CDN, and after the purge, i was able to get the modified version of the file. But, if i request the file to the cdn edge with any querystring parameter, i get the original version of the file, instead of the modified version of the file.
Example requesting the file via edge:
w/o qs: https://#storage_account#/#file_path#/hh.min.css -> It gives me the modified version
w qs: https://#storage_account#/#file_path#/hh.min.css?v=0.5 -> It gives me the original version
w qs (2): https://#storage_account#/#file_path#/hh.min.css?a=b -> It gives me the original version
Any idea why this is happening?
Thanks.
Most likely what's happening is the use of the query uses a cached asset, as mentioned per the documentation
Ignore query strings: Default mode. In this mode, the CDN point-of-presence (POP) node passes the query strings from the requestor to the origin server on the first request and caches the asset. All subsequent requests for the asset that are served from the POP ignore the query strings until the cached asset expires.
So my guess is the cached asset did not expire yet. To avoid this issue, you should consider bypassing the caching for query strings:
Bypass caching for query strings: In this mode, requests with query strings are not cached at the CDN POP node. The POP node retrieves the asset directly from the origin server and passes it to the requestor with each request.
If the above option results in latency, I'd recommend adjusting the caching rules.
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!
I working with mediawiki.
I want to change upload directory path to aws s3, i tried these two extensions but i getting some warning message.
I dont know these extension are working correctly.
https://www.mediawiki.org/wiki/Extension:LocalS3Repo and
https://www.mediawiki.org/wiki/Extension:AWS
If anybody is working with these extension or if you achieved these in any other ways
please explain me
I have been succesfully using the method described here, though in step 6, rather than using an apache rewrite, I changed the image paths in LocalSettings.php.
(It was quite a lot of work though, and I never figured out a way to the the cache-control and expires headers on the files, which was the real reason why I wanted to do it to begin with.)