Hacker News Reader

Comment by jim_lawless | Hacker News Reader

I have seen some success in controlling caching of JS files by appending a query-string ( including something such as a timestamp of the JS file ) to the end of the URL.

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.

View on HN

Rails does this automatically with JS and CSS files called by the built in helpers.

Also can cache a number of js files into a single JS file for better performance.

I've had similar success by appending the site version to the query string. src="/foo.js?v=2.1" This has worked for me across all major browsers and required extremely little work for setup and maintenance.

This requires all api changes to touch the version (to be pedantic) which then becomes a major source of version control conflicts (in my experience).

Unfortunately, this doesn't work with cloudfront, so you have to put the uniq string as part of the file/key name

Yup, I do the same for CSS files

Tahts exactly what I did about 6 months ago. "/path/file.js?varsion=timestamp" where timestamp is:

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.

But it doesn't solve the problem where the browser caches the html but not the one of the js files. In this case the user would load one .js file (?version=old) and get the new .js file because they are all pointing to the same file on the disk (url parameters are not separate files). By physically naming the file after the hash you are guaranteed to get either the old set of files or the new set of files.

I'm not exactly sure what you mean.

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.

Yes, but file.js is on the disk and is always the new version.

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.

Reply on news.ycombinator.com