How we hash our Javascript for better caching and less breakage on updates

Re:How we hash our Javascript for better caching and less br... by __david__ on Wednesday September 02, 2009 @03:29PM (#800915)

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.

[ Parent | on HN ]

Re:How we hash our Javascript for better caching and less br... by mikeryan on Wednesday September 02, 2009 @05:08PM (#801117)

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.

[ Parent | on HN ]

Re:How we hash our Javascript for better caching and less br... by __david__ on Wednesday September 02, 2009 @06:16PM (#801237)

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.

[ Parent | on HN ]