[ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1890:
-----------------------------------------

    Assignee: Alessandro Bellina

> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: STORM-1890
>                 URL: https://issues.apache.org/jira/browse/STORM-1890
>             Project: Apache Storm
>          Issue Type: Improvement
>          Components: storm-ui
>    Affects Versions: 2.0.0, 1.1.0
>            Reporter: Alessandro Bellina
>            Assignee: Alessandro Bellina
>            Priority: Minor
>
> 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:
> {code}
> <script src="/js/script.js?_ts=${timestamp}" type="text/javascript"></script> 
> {code}
> instead of:
> {code}
> <script src="/js/script.js" type="text/javascript"></script>
> {code}
> 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:
> {code}
> $.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to