When I navigate to my Azure static web app using Chrome I'm suddenly seeing an old version from months ago. It seems that several others have had this issue over the years (e.g. here), but I couldn't find any definitive solution anywhere.
Things I've tried:
Disabling cache in 'Developer Tools' on Chrome then right-clicking on the refresh button and selecting 'Empty cache and hard reload'. This lets me see the latest (correct) version of the site ... but once I navigate away and return I get the old version again.
Using Chrome incognito mode. This gets me the latest (correct) version of the site.
Using my phone, or using another non-Chrome browser also gets me the latest (correct) version of the site.
Unsetting my custom domain as the default for the site (under Settings > Custom domains) then navigating to the site's azurestaticapps.net address gets me the latest (correct) version of the site.
It seems that some sort of caching is going on when using my custom domain, but I can't seem to fix it. Interestingly, the version of the site that I'm seeing was a version from months ago when I last used that custom domain. Back then I'd linked the custom domain to a different version of the static web app launched under a different azurestaticapps name.
I am working on a site. I got this from a client to be redesigned. The old design was made by some other agency. Once I was done, and changed old DNS records to the new server and went live with the new design, everything worked OK. Except, for old users of the site.
All old users couldn't see the new design. I did everything I could to force the browser to forget cache by using HTTP Headers, .httaccess etc. Nothing worked.
I later found that the old design was built on PWA technology. Progress Web Apps which can be installed as an app on the device. And this app used something called worker cache to store static files in the Cache Storage and Application cache.
Now for some reason, old users' browsers are not willing to forget that cache at all. Looks like the browser isn't even hitting my new server / DNS settings for the new design. It just takes the content from the worker/application cache and displays the old site.
I can't ask users to clear their cookies or cache, or uninstall the app individually. How can I get rid of this cache from old users' browsers so that the new design is working on those devices too?
Any ideas?
Browsers do cache a lot of JS and CSS files. How do sites like Facebook work around this issue whenever they release new production code? Do they do cache busting to do this in all their resources? I do see these jumbled up characters in all their image files at least.
Generaly what they do add a version number or some unique code at the end of java script urls in the html file like
http://your_js_url?v=2
whenever there is a new version they just change the v=2 to v=3 that refreshes all user browser cache
Same for css url
I have an Orchard 1.6 site hosted on Windows Server 2012, IIS 8.5, .NET 4.0.
I need to add a link to a network-hosted file into my Orchard menus, where the network share is accessible from my web server - the destination file itself resides on a different server. I put in file://path/to/network/file in the Custom Link menu URL, but the base URL of the site always gets prepended to the link.
E.g., if my base URL is http://example.com, the link becomes http://example.com/file://path/to/network/file, and then .NET does not like the second : in the path - on top of it being the incorrect link. No combination of forward-slashes, backslashes, or other symbols prevents the prepended base URL.
To add another wrinkle to this, the same URL scheme works fine with a slightly different setup: Orchard 1.6, Windows Server 2008, IIS 7.0, .NET 4.0; web server and destination network URL are on the same server.
Is there a way to force Orchard to use the URL as given, without changing it at all? Alternatively, where is the code that constructs the final link?
Using a 'HTML menu item' instead of 'Custom link' to insert raw HTML as a link does work, but that seems like a pretty kludgy workaround; I have to do this for a few dozen links, and I won't necessarily be the one to change them later on.
I've looked into Orchard settings and IIS settings; neither has anything about rewriting links. Changing the base URL on Orchard to match the expected destination server doesn't work (and wouldn't be acceptable long-term). I've also tried hosting a temporary local file (c:\temp\test.txt) but I can't even get that to produce the correct file:// destination on the new setup.
Upgrading to the latest Orchard (1.8.x) is not a feasible solution (if that even ends up being a possible solution).
Edit:
I should clarify that both sites are on an intranet; I'm aware of the security implications associated with file:// links, and the problems with getting various browsers to load them properly, but I want to get the link generation working first.
Edit: problem source
I figured out why link handling was inconsistent between my own sites - I had written a small chunk of Javascript in the first site to strip the application's base URL for any file:// links it encountered. I forgot that it was there and hardcoded to remove only a certain base URL, so when I moved the site to a different hostname, it broke.
So, no inconsistency in Orchard, just my own faulty memory.
Orchard deliberately limits menu links to mailto, tel, http, and https protocols, and excludes all others, such as file and ftp (see navigationmanager.cs). If you want to use other protocols, you will have to use another type of menu item, but please keep in mind that the file protocol is unsafe and is not supported by all browsers, for security reasons (see for example http://kb.mozillazine.org/Links_to_local_pages_do_not_work). Even Internet Explorer has stopped supporting it in the Internet zone since IE6 SP1: http://msdn.microsoft.com/en-us/library/aa767731(v=vs.85).aspx
Note: I originally posted this on ServerFault, but I haven't gotten any responses at all. Since it looks like I'm on track to get the Tumbleweed badge over there, I figured I would try here also.
Our existing public website consists of a mish-mash of asp.net pages with mostly static content and some real web applications that are set up as virtual directories. We're now looking at installing Umbraco, which requires that you install it at the root of the website.
Since the CMS would be at the root of the website, I'm assuming it's a bad idea to run our existing pages and web applications underneath Umbraco (due to the URL rewriting it performs and inheriting web.config settings, etc.) So how do we make everything co-exist peacefully both while we transition to the CMS and after we're finished?
My only idea so far was to set up the CMS and the applications as separate websites and then use some sort of URL rewriting/reverse proxy to make everything resolve correctly:
* www.example.com would keep resolving to our old homepage
* www.example.com/dept1 would keep resolving to the old dept1 page
* www.example.com/dept2 would resolve to the new dept2 page on the CMS
* www.example.com/app would resolve to an existing web application
We ending up setting up Umbraco as it's own website in IIS and then we bought ISAPI Rewrite so that we could seamlessly pass through CMS content for certain URLs.