[ACCEPTED]-Is it the filename or the whole URL used as a key in browser caches?-filenames

Yes, any change in any part of the URL (excluding 21 HTTP and HTTPS protocols changes) is interpreted 20 as a different resource by the browser (and 19 any intermediary proxies), and will thus 18 result in a separate entity in the browser-cache.

Update:

The 17 claim in this ThinkVitamin article that Opera and Safari/Webkit browsers 16 don't cache URLs with ?query=strings is 15 false.

Adding a version number parameter to a 14 URL is a perfectly acceptable way to do 13 cache-busting.

What may have confused the 12 author of the ThinkVitamin article is the 11 fact that hitting Enter in the address/location 10 bar in Safari and Opera results in different 9 behavior for URLs with query string in them.

However, (and this is the important part!) Opera 8 and Safari behave just like IE and Firefox when it comes to caching embedded/linked 7 images and stylesheets and scripts in web 6 pages - regardless of whether they have 5 "?" characters in their URLs. (This 4 can be verified with a simple test on a 3 normal Apache server.)

(I would have commented 2 on the currently accepted answer if I had 1 the reputation to do it. :-)

Browser cache key is a combination of the 11 request method and resource URI. URI consists 10 of scheme, authority, path, query, and fragment.

Relevant 9 excerpt from HTTP 1.1 specification:

The primary cache key consists 8 of the request method and target URI. However, since 7 HTTP caches in common use today are typically 6 limited to caching responses to GET, many 5 caches simply decline other methods and 4 use only the URI as the primary cache key.

Relevant 3 excerpt from URI specification:

The generic URI syntax consists 2 of a hierarchical sequence of components 1 referred to as the scheme, authority, path, query, and fragment.

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

I am 99.99999% sure that it is the entire 3 url that is used to cache resources in a 2 browser, so your url scheme should work 1 out fine.

The MINIMUM you need to identify an HTTP 15 object is by the full path, including any 14 query-string parameters. Some browsers may 13 not cache objects with a query string but 12 that has nothing to do with the key to the 11 cache.

It is also important to remember that 10 the the path is no longer sufficient. The 9 Vary: header in the HTTP response alerts 8 the browser (or proxy server, etc.) of anything 7 OTHER than the URL which should be used 6 to determine the cache key, such as cookies, encoding 5 values, etc.

To your basic question, yes, changing 4 the URL of the .js file is sufficent. TO 3 the larger question of what determines the 2 cache key, it's the URL plus the Vary: header 1 restrictions.

depends. it is supposed to be the full URL, but 10 some browsers (Opera, Safari2) apply a different 9 cache strategy for urls with different params.

best bet is to change the name of the file.

There 8 is a very clever solution here (uses PHP, Apache)

http://verens.com/archives/2008/04/09/javascript-cache-problem-solved/

Strategy notes: “According 7 the letter of the HTTP caching specification, user 6 agents should never cache URLs with query 5 strings. While Internet Explorer and Firefox 4 ignore this, Opera and Safari don’t - to 3 make sure all user agents can cache your 2 resources, we need to keep query strings 1 out of their URLs.”

http://www.thinkvitamin.com/features/webapps/serving-javascript-fast

Yes. A different path is the same from the 1 caches perspective.

Of course it has to use the whole path '/r20/example.js' vs 3 '/r21/example.js' could be completely different 2 images to begin with. What you suggest is 1 a viable way to handle version control.

Entire url. I've seen a strange behavior 2 in a few older browsers where case sensitivity 1 came into play.

In addition to the existing answers I just 5 want to add that it might not apply if you 4 use ServiceWorkers or e.g offline-plugin. Then 3 you could experience different cache rules 2 depending on how the ServiceWorkers are 1 set up.