Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

Currently we don't employ cache busting techniques in the Storm UI while fetching script.js, CSS and templates. Ring is providing the Last-Modified header, but browsers implement a heuristic to when they deem a resource stale (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means that as the Last-Modified for a resource is further away in the past, the longer the browsers are going to wait until they refetch. It looks like 10% padding is common, so if script.js was last modified 100 days ago, the browser will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever storm is packaged (mvn package). A more complicated method is versioning the files (we'd need to specify them in the pom.xml individually using the assembly plugin, unless we use some other plugin). The first method is (was?) considered less effective, since some CDNs/browsers can decide not to cache the query parameter.

I'd like to go with the simpler method, unless there are strong opinions to changing file names (this means we need to specify files in the assembly pom.xml). Also, going this route we don't need any new plugins, and the assembly build can just be changed to export a variable. We would modify calls to include a value that changes on mvn package:

<script src="/js/script.js?_ts=${timestamp}" type="text/javascript"></script> 

instead of:

<script src="/js/script.js" type="text/javascript"></script>

Where ${timestamp} will be replaced at assembly time by maven. This would be the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to ajaxSetup will do the trick. For example:

$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});