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.
Related
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?
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?
I am making some changes to the css file for a website and I found out that my changes are disregarded.
In order to diagnose the problem, I deleted the only css file I have (default.css) from the server.
To my surprise, all web browers (Chrome, Firefox, IE11) are still capable of seeing and downloading the file. So, if I go to www.example.com/default.css, I can download the file despite the fact it is not there anymore! I used the command Ctrl + F5 to clear the local cash from browsers and reload the file default.css, but the file is still there and it contains the old version. I also used Ctrl + Shift + Del to clear everything in IE browser. Earlier today I created the file .htaccess to redirect example.com to www.example.com. I also use the services of cloudflare.
If I upload to the same location a different file, default2.css, I can view it correctly.
Any idea who delivers to me the old file? I suspect it may be cloudflare. I host my website on runhosting.com
Thanks,
Nick
Did you purge the file in CloudFlare?
CSS is a file CloudFlare caches & you would want to purge it if you make a change to static content we cache.
I have a client who installed our silverlight app recently. it works fine from their server itself. but when they try to run it from a client, they can log in through the aspx login page, but on the main page, which hosts the tag and the .xap file, they see absolutely nothing!
I cannot see their screens, just get occasional screenshots via email and cross my fingers that they are typing the URL I tell them to. Even Shareview is not working for them - they can see my screen but I cannot see theirs.
So I am pleading - help! Please throw out some wacky ideas. I just learned an hour or so ago that they did not even have silverlight installed, so the mornings debugging effort was a waste of time. So who knows what the next fascinating source of problems is?
Here is the user-agent info. Oor app is .net 4.0 could that be the problem? It does noty look to my untrained eye that the client supports 4.0 (from the web server log):
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 401 3 5 0
Getting closer - I see that the GET request for the XAP is returning 401 - not found! What would do that?
It's very possible that they are blocking XAP files either directly or indirectly at the firewall. XAP files are simply ZIP files and inspection-based firewalls tend to look at these as a security risk. You may want to see if they can setup an exception in their rules.
Hmm..
1) check if your client access the good url. Request their IP address, then check the web server logs. ie: are they requesting the good url, are they downloading the xap? (check if they use a proxy, too?)
2) check that they restarted their browser after installing the Silverlight runtime.
3) Do you handle the UnhandledException event for your Application class? If no, use it to send detailed exception logs to your server on application crash.
4) Use javascriptto initialize your Silverlight application. This way, you can be notified if the runtime fail to start, (for example if it failed to load the xap file) You can use ajax to report the issue to the webserver.
The company I work for has proxies/WAN accelerators between our international sites to cache Intranet web content. I have a Silverlight application being hosted on a server at one location, but being accessed by clients in another location. When the users access the web page hosting the Silverlight app, they get the stale xap file being cached by the proxy and not the latest version from the server. Local users always get the latest xap as their requests are not going through a proxy.
I've tried the various header/metadata techniques mentioned elsewhere to prevent caching, and the containing web page itself is being served up fresh, but I still get the old .xap file. Short of getting our IT admin to disable proxy caching for my site, is there anything I can do make sure the latest xap file get retrieved from the server instead of the proxy? The containing page is ASP.NET.
What I do is just add a querystring at the end of the path to the xap file. Then when you change the querystring variable, the proxies etc. should see it as a request to a new file. So far this has worked fine for me.
So basically, when embedding an .xap in a straight-up HTML file, you would do this:
<param name="source" value="ClientBin/SilverlightApplication1.xap?cachepreventer=whatevervalue"/>
And then when you deploy a new version, just change "whatevervalue" to something else.
EDIT
If you need to use this technique in many places in your app I would read the querystring value from config and just write it to the page using asp.net. That way you only need to update it in one place when you deploy.
If you want to make sure every time the xap file is retrieved and you don't want to worry about it - just use
<param name="source" value="ClientBin/YourSilverlightapp.xap?<%=Guid.NewGuid().ToString() %>"/>
of course - this lends itself to a heavier cache load. I do like the helper method above though if you only want changes to be propagated to the client.