Also can cache a number of js files into a single JS file for better performance.
A) The last modified time of the file in milliseconds B) The current time milliseconds if in debug mode
Depending on if debug mode is turned on the minified file or original is served to the client. I minify on-demand since it's so fast and files rarely change, only the first request takes the hit and it is not a big hit, maybe 1 or 2 seconds.
I serve the pages with a 1 yr expiration time for these files.
I do the same for CSS.
It works very nicely :) NEVER have to clear a browser's cache when developing and garantee that all users always have the latest code.
file.js?11111 and file.js?22222 are considered separate files and would get redownloaded by the browser.
The URL parameters are significant in browser caching.
If the html is cached then it will still have the old reference to file.js?1111. If it goes and gets that from your site it will not get the old one it will get the new one. In which case you now have a mismatch and you can get errors.
With the hashing scheme this does not happen. The html references file-oldhash.js which still exists on the server in its original form. Therefore, your pages are atomic--either you will have all new scripts or all old scripts. Which is exactly what you want--it's the mismatch between new and old that causes problems.
script src="/whatever.js?x=09_02_2009_08_15_AM
Various versions of IE and Mozilla Firefox seem to treat this as a unique URL because of the query-string, even if whatever.js is in the cache. The caching proxies that I've dealt with seem to handle this, but I'm not sure that all of them would ... so the author's approach is much more reliable.