recently we made changes to one of our applications and we noticed that our customers are not getting the new views. So we decided to version the files so we can force the client's browsers to fetch the new views every time we have a new version.
So far so good, but we needed to test this in a local environment before deploying this change (the versioning). Unfortunately, on localhost the views are never cached. I noticed that the requests for the views are sent with Cache-Control:max-age=0. If I am not mistaking this causes the resource to not be cached.
I read also that this could be caused by the ETag header, so I removed it but the views are still not cached. Also, I set the Cache-Control:max-age=86400,public header in the response. So the only reason left was the Cache-Control:max-age=0 header in the request. So I tried to change the header. I set the cache-control header in the request to be Cache-Control:max-age=86400,public, but still no luck.
The views are requested by AngualarJS, they are templates in directives. There is also a difference in the IIS version that we are using locally and that on the server. Locally we are using 7.5 and on the server, it is 8.0. Could this be the problem?
Can anyone guide me to the right direction?
Edit:
The Disable Cache option in the chrome dev tools is disabled.
One thing I can think about is that you have the Disable Cache enabled in your browser, if it's just your local system:
Normally, getting around Browser caching is quite tricky, so most people have trouble disabling browser caching using headers. The Cache-Control:max-age unfortunately is not uniformly implemented across browsers. If the issue is still occurring inspite of the above, could you provide screenshots from the network tab on your Chrome developer tools?
Related
I am currently using versioning to bust cache. I used to generate different file name with date or version. However, it breaks google cached page because google look for the old file name.
I have a webpack setup for the chunking.
output.filename = '[name].js?v=' + hash
output.chunkFilename = '[name].js?v=' + hash
And I can see that browser requesting file with v=xxx correctly
However, sometimes I need to ask my customer to open up dev tool and click clear cache and hard refresh because normal refresh does not work somehow.
I also use Cloudflare cdn and it does have cache policy.
Cloudflare response headers.
cache-control: max-age=31536000
cf-bgj: minify
cf-cache-status: HIT
cf-polished: origSize=9873
How to make sure browser and cloudflare purge all the js and css files when the new code is pushed ?
Do not know what to do when normal refresh does not work.
On Cloudflare there are several ways to control the behavior of the cache
Understanding the Cloudflare CDN (general rules)
Cache level (can be configured to consider or ignore the querystring)
Page Rules (useful to fine tune caching behavior based on URL patterns)
Origin Cache Control (to control the behavior based on the cache headers returned by your origin server)
You also have various options (depending on the plan) for proactively purging certain resources with Cache Purge (both from the dashboard or via APIs).
It is worth reviewing the above settings (in particular cache levels and page rules) to verify that the querystring is being considered part of the cache key used to retrieve the data. In particular, the header cf-cache-status: HIT indicates that the requested resource was fetched from the CDN cached copy.
I am building a react app, which consists in a Single Page Application, hosted on Amazon S3.
Sometimes, I deploy a change to the back-end and to the front-end at the same time, and I need all the browser sessions to start running the new version, or at least those whose sessions start after the last front-end deploy.
What happens is that many of my users still running the old front-end version on their phones for weeks, which is not compatible with the new version of the back-end anymore, but some of them get the updates by the time they start the next session.
As I use Webpack to build the app, it generates bundles with hashes in their names, while the index.html file, which defines the bundles that should be used, is uploaded with the following cache-control property: "no-cache, no-store, must-revalidate". The service worker file has the same cache policy.
The idea is that the user's browser can cache everything, execpt for the first files they need. The plan was good, but I'm replacing the index.html file with a newer version and my users are not refetching this file when they restart the app.
Is there a definitive guide or a way to workaround that problem?
I also know that a PWA should work offline, so it has to have the ability to cache to reuse, but this idea doesn't help me to perform a massive and instantaneous update as well, right?
What are the best options I have to do it?
You've got the basic idea correct. Why your index.html is not updated is a tough question to answer to since you're not providing any code – please include your Service Worker code. Keep in mind that depending on the logic implemented in the Service Worker, it doesn't necessarily honor the HTTP caching headers and will cache everything including the index.html file, as it seems now is happening.
In order to have the app work also in offline mode, you would probably want to use a network-first SW strategy. Using network-first the browser tries to load files from the web but if it doesn't succeed it falls back to the latest cached version of the particular file it tried to get. Another option would be to choose what is called a stale-while-revalidate strategy. That first gives the user the old file (which is super fast) and then updates the file in the background. There are other strategies as well, I suggest you read through the documentation of the most widely used SW library Workbox (https://developers.google.com/web/tools/workbox/modules/workbox-strategies).
One thing to keep in mind:
In all other strategies except "skip SW and go to the network", you cannot really ensure the user gets the latest version of the index.html. It is not possible. If the SW gives something back from the cache, it could be an old version and that's that. In these situations what is usually done is a notification to the user that a new version of the app has been donwloaded in the background. Basically user would load the app, see the version that was available in the cache, and SW would then check for updates. If an update was found (there was a new index.html and, because of that, new service-worker.js), the user would see a notification telling that the page should be refreshed. You can also trigger the SW to check for an update from the server manually from your own JS code if you want. In that situation, too, you would show a notification to the user.
Does this help you?
I have a MEAN app in production on Digital Ocean, but have observed strange behavior when recently migrating a new Bootstrap theme to replace the previous designs. What I've noticed is that even after I replaced the code that included certain elements, such as a background image, the webserver would still be looking for them.
Failed to load resource: the server responded with a status of 404 (Not Found) https://www.website.com/img/frontpage-img.jpg
I even grepped from the root directory to ensure frontpage-img.jpg was no longer included anywhere within the codebase, and got
Binary file .git/index matches
as the only result. This behavior is also not replicated on the localhost, which works exactly as I expect it to. Is this a server-related issue? How do I purge the old elements to prevent the server from trying to load them?
We are using the WCF-RIA Services in our project.
On part is a search which will trigger a RIA request on the server.
For this request we have enabled the Client output cache using this attribute:
[OutputCache(OutputCacheLocation.Client, duration: 2 * 60)]
We want to use the client cache, because the information to be cached are user specific. The problem ist, that the cache works fine in Firefox and IE after the application is installed in an IIS, but while debugging IE seems to ignore the caching.
Maybe this is not really a RIA Service specific problem but more of an IE problem. It looks as IE sees "Hey, this is a request to localhost, I don't want to cache that" (some kind of feature).
This is a bit unhelpful, because the debugging situation is not the same as the "live" situation.
Is there a way to use the WCF-RIA Services client cache in IE while debugging?
You should be able to test this using either your machine name in the URL or using localhost. (note the dot at the end) instead of localhost. See here for more info.
Once you have it working with Fiddler you should be able to see if your caching is on or off and debug it.
I have a sample program which does nothing but Hello World. I open IE and go to my development environement and access the silverlight, it loads the XAP first time and then if I close IE and open again, XAP does not get downloaded. Since there are no changes I expect it not to download.
After deploying it in QA environement, I open IE for the first time, it load XAP as expected. Now close IE and open again, I expect it not to download XAP but it does download XAP again. But if I would do refresh on the page it does not download XAp. So this happens only on Fresh IE open in our QA environment.
All the above tests are done on the same box with same IE setting. So there is no client side IE cache issue. I did check the date and Time on the servers to see if there is any difference as specified in silverlight XAP gets downloaded everytime
link and our servers are in same date and time.
Does any one know how to prevent IIS not to download everytime?
The default settings in IE mean that a fresh instance of IE will always attempt to fetch each unique URL when it is first encountered. IE does this even if the cache headers sent with the resource the last time it was fetched would indicate the resource is still fresh.
However IE will send If-Modified-Since and/or If-None-Match when it re-requests a resource that it has a copy of in its cache. Hence the server has the option of responding with 304 Not Modified, are you sure that is not happening? The 304 has no entity body and is therefore a cheap response.
Note also that IE can make some strange heuristic choices if the server fails to send any cache control headers with a resource. One of these choices is where the resource is quite large no caching is performed.
If you haven't already done so I would recommend you set some reasonable Expiration on the ClientBin folder in IIS Manager (in IIS7 select the ClientBin folder, select "HTTP Response Header", open "Set Common Headers..", enable Expire Web content.