I am using IE 7.0. I want to clear the cache for every new request. So i need java script code for clear the cache. In IE i am using one setting to fix the caching issues. This is location:
Tools-Internet Options-Browsing History Settings-Every time i visit the web page-Ok.
It works fine for the current IE browser. Now I need to implement this concept using Java script. Please suggest me.
Response.Buffer = False
Response.CacheControl = "no-cache"
I tried, but not working.
You can't clear the cache using JavaScript. You can, however, trick the browser into thinking the page is different than what is stored in the cache by appending a number to the end of the URL.
So, for example, if you want to ensure that the browser is using your latest JS, append a number to the end of the source attribute (a different number will be needed each time you wish to "trick" the browser caching):
<script src="myScript.js?1" />
If you want to clear the cache for the entire page, you need to be asking a different question: How to control caching with [enter server-side language here]?
Note: Your new question, if needed, should be asked in a new question on SO.
Related
I'm using Liferay CMS as part of my Uni course in full stack development and, as a final project, I have to use the d3.js library to display some graphs. I'm struggling to clear the browser cache though, and that makes the developing process very tedious and time consuming: I'd like to see my front-end changes right away without having to fiddle with the browser cache, especially because, as I'm working with svg elements, it sometimes gets tricky to line up stuff and so on. Sometimes clearing the cache works, sometimes it doesn't, as well as opening a new private window, but there must be a conclusive and foolproof method to delete all cached elements. Does somebody know how to do that?
Liferay has a "Developer Mode" which should bypass quite a lot of caching anyway. In your portal-ext.properties (typically in ${liferay.home}, just add the line
include-and-override=portal-developer.properties
to activate this mode.
It will also skip minifiers and concatenation of all of the different resources that you're loading.
This doesn't clear caches but will solve your updating problem.
In the HTML, add an (unused) query string to the html link to linked files and alter it each time you make an update to the file. e.g. for css:
<link rel="stylesheet" href="styles.css?a">
Then, each time you make changes to the file pointed to, change the 'a' to 'b' or anything (Don't change the linked file's name, the query string will be ignored).
This forces the browser to 'change' the linked file each time the href changes and so the altered file gets reloaded.
The method will work for script and other linked files. The query string could be something meaningful such as version numbers - ?v1, but anything will do.
Edit, as noted by #GerardoFurtado, a further discussion of this idea is available here Cache busting via params
I have seen many websites that include at their JavaScript and CSS external resources things like this:
filename.js?v=3cc1b79c2abb
And:
filename.css?v=7bbb71ecd5eb
The "?v=..." things at the end...
What is this? And for what is this useful?
Thank you!
Cheers :)
These are a form of "Cache Busting" - they force the browser to download the latest version of the file, rather than taking a chance at loading an old file from cache.
There is something more deeper - why do we need cache busting?
For efficiency sake we have to make the browser cache the resource files. For that to work we set last modified date as a very old date (say, 01-Jan-1970 00:00:00.000) and expiry date long into the future. These 2 things will make the browser cache the files so that they are not requested from the server again. That is very efficient. However, that causes a problem when you update the application. None of the resources will be downloaded again! To work around that we configure the build tool to append a version number query string unique to the build at the end of resource URLs. It is typical to use build timestamp or a uuid or the source repository version number (in case of version control tools like SVN which give a unique version number to every commit) as the version number string appended to the end of the resource URLs. That forces the browser to download new version whenever the application is updated.
This is your own version/keyword v=7bbb71ecd5eb of js and css, After use this, there would not be cache in browser with your older javascript and css.
Which means your new update of css and javascript would be applied without any cache.
It's to force the browser to download the file instead of getting it from cache.
For example, you have this url with css : styles.css?v=blablabla, but later you change css and want to have these changes to be seen instantly (instead of waiting when browser cache will expire or forcing user to press Ctrl + F5) you change it to something like styles.css?v=otherblablabla. Browser sees it as different url so it have to download it.
It's just a parameter in query string, and because the url points to static resource, these parameters are ignored by web server.
You could also see something like this image.png?1392469113262. It's just a parameter named 1392469113262 that has no value. image.png is static resource so this parameter will be ignored by server. These numbers are usually some timestamp and it's the often the best way to force browser to not cache image (or any other resource).
When I saw many sites' source code, parameters were passed to the linking file (CSS/JavaScript).
In the Stack Overflow source, I got
<script type="text/javascript" src="http://sstatic.net/js/master.js?v=55c7eccb8e19"></script>
Why is master.js?v=55c7eccb8e19 used?
I am sure that JavaScript/CSS files can't get the parameters.
What is the reason?
It is usually done to prevent caching.
Let's say you deploy version 2 of your new application and you want to cause the clients to refresh their CSS, you could add this extra parameter to indicate that it should re-request it from the server. Of course there are other approaches as well, but this is pretty simple.
As the others have said, it's probably an attempt to control caching, although I think it's best to do so by changing the actual resource name (foo.v2.js, not foo.js?v=2) rather than a version in the query string. (That doesn't mean you have to rename files, there are better ways of mapping that URL to the underlying file.) This article, though four years old and therefore ancient in the web world, is still a quite useful discussion. In it, the author claims that you don't want to use query strings for versions because:
...According the letter of the HTTP caching specification, user agents should never cache URLs with query strings. While Internet Explorer and Firefox ignore this, Opera and Safari don’t...
That statement may not be quite correct, because what the spec actually says is
...since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time...
(That emphasis at the end is mine.) So using a version in the query string may be fine as long as you're also including explicit caching headers. Provided browsers implement the above correctly. And proxies do. You see why I think you're better off with versions in the actual resource locator, rather than query parameters (which [again] doesn't mean you have to constantly rename files; see the article linked above for more). You know browsers, proxies, etc. along the way are going to fetch the updated resource if you change its name, which means you can give the previous "name" a never-ending cache time to maximize the benefit of intermediate caches.
Regarding:
I am sure that Js/CSS files can't get the parameters.
Just because the result coming back is a JavaScript or CSS resource, it doesn't mean that it's a literal file on the server's file system. The server could well be doing processing based on the query string parameters and generating a customized JavaScript or CSS response. There's no reason I can't configure my server to route all .js files to (say) a PHP handler that looks at the query string and returns something customized to match the fields given. Thus, foo.js?v=2 may well be different from foo.js?v=1 if I've set up my server to do so.
That's to avoid the browser from caching the file. The appending version name has no effect on the JavaScript file, but to the browser's caching engine it looks like a unique file now.
For example, if you had scripts.js and the browser visits the page, they download and cache (store) that file to make the next page visit faster. However, if you make a change the browser may not recognize it until the cache has expired. However, scripts.js?v2 now makes the browser force a re-fetch because the "name's changed" (even though it hasn't, just the contents have).
A server-side script generating the CSS or JavaScript code could make use of them, but it is probably just being used to change the URI when the the content of the file changes so that old, cached versions won't cause problems.
<script type="text/javascript">
// front end cache bust
var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];
for (i=0;i<cacheBust.length;i++){
var el = document.createElement('script');
el.src = cacheBust[i]+"?v=" + Math.random();
document.getElementsByTagName('head')[0].appendChild(el);
}
</script>
This is to force the browser to re-cache the .js file if there has been any update.
You see, when you update your JS on a site, some browsers may have cached the old version (to improve performace). Sicne you want them to use your new one, you can append something in the query-field of the name, and voíla! The browser re-fetches the file!
This applies to all files sent from the server btw.
Since javascript and css files are cached by the client browser, so we append some numeric values against their names in order to provide the non-cached version of the file
"I am sure that JavaScript /CSS files can't get the parameters"
function getQueryParams(qs) {
qs = qs.split("+").join(" ");
var params = {},
tokens, re = /[?&]?([^=]+)=([^&]*)/g;
while (tokens = re.exec(qs)) {
params[decodeURIComponent(tokens[1])] = decodeURIComponent(tokens[2]);
}
return params;
}
This is referred to as Cache Busting.
The browser will cache the file, including the querystring. Next time the querystring is updated the browser will be forced to download the new version of the file.
There are various types of cache-busting, for example:
Static
Date/Time
Software Version
Hashed-Content
I've wrote an article on cache busting previously which you may find useful:
http://curtistimson.co.uk/front-end-dev/what-is-cache-busting/
I have a list of js files, css and images which doesn't need to load from server every time, but if there is any update in files or bug fixes, only during that time I want to replace the files from browser cache, I know there is no access to browser cache, but is there any other ways to do so? My application will be used by specific users (known people), where I can install any program in their system, can anybody suggest me efficient way to do so? I don't want to load the files every time from server by setting 'no-cache'.
The most effective way to force the browser to refresh certain files at certain times is to add an arbitrary extra query string to the link:
<script type="text/javascript" src="http://mywebsite.com/js/scripttoload.js"></script>
then change to:
<script type="text/javascript" src="http://mywebsite.com/js/scripttoload.js?V=2"></script>
Next time the page is requested the browser will think this is a new file. There are loads of other ways with headers etc but this works well
No, there isn't.
Javascript doesn't have access to the cache - the browser doesn't expose this information to the javascript engine.
A commonly-used trick is to set the cache for the files to last for ages, so that they aren't requested again. However, when you want them to be updated, you can append a timestamp to the filename after a question mark. EG:
<link rel="stylesheet" href="style.css?123211212"/>
Every time the number changes, the browser thinks it's a different file and will re-download it. If the number doesn't change, then it uses the cached version.
What I do is, as part of the build process, rename all the statically referenced files to something involving their md5 hash. Then I set the headers so that they're cached for the max possible time. As soon as they change, they get a new name, so there's never an issue.
I'm working on an asp.net website. I need to make sure my javascript and css updates will be immediately available for returning visitors, without them having to clear their cache to get the latest code. How can I force this when needed, and leave it alone on other occasions?
Thanks in advance.
Stackoverflow does this very elegantly IMO. You can see in there source there is a query-string variable passed.
<script type="text/javascript" src="http://sstatic.net/js/stub.js?v=778aaf5a38e2"></script>
This will force new load if that changes.
In order to reliably force a refresh of cached content on the browser you need to change the name / requested URL of the file somehow.
Often this is done by appending a query string to the URL (which is often ignored)
See When Does Browser Automatically Clear JavaScript Cache? for a more complete discussion.
You'll need to apply no-cache header to those resources, alternatively make the url dynamic somehow.
see - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html