[
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329508#comment-15329508
]
ASF GitHub Bot commented on STORM-1890:
---------------------------------------
GitHub user abellina opened a pull request:
https://github.com/apache/storm/pull/1486
STORM-1890: ensure static UI resources are re-requested with differen…
…t Storm package builds
Note it doesn't perform cache busting for logviewer. That is creating its
own HTML, where I think it can be refactored to use some static file in
public/, that is a separate task.
Thanks! I'll backport to 1.x if this looks good.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/abellina/storm
STORM-1890_ensure_we_refetch_static_resources_after_package_build
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/storm/pull/1486.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1486
----
commit 76a5e72e7cbdf9d9b32f5683d2bf5054ec0e2291
Author: Alessandro Bellina <[email protected]>
Date: 2016-06-14T12:39:45Z
STORM-1890: ensure static UI resources are re-requested with different
Storm package builds
----
> 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
> 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)
