Why pass parameters to CSS and JavaScript link files like src="../cnt.js?ver=4.0"?

Question

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?

Answer 1

<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> 

Answer 2

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/

Answer 3

"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;
}

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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).

Answer 8

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.

Answer 9

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.