[jira] [Commented] (GUACAMOLE-275) Control caching of extension JS/CSS

["Michael Jumper (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16579145#comment-16579145 ] 

Michael Jumper commented on GUACAMOLE-275:
------------------------------------------

Using "Cache-Control: no-cache" should actually be OK so long as we make proper use of E-Tags. We can achieve this through:

* Dynamically generating a unique, random token when the webapp is started.
* Filtering {{index.html}} at runtime, substituting that token where we previously would have placed the webapp version.
* Serving the filtered {{index.html}} with {{Cache-Control: no-cache}} and proper E-Tags, such that it will always be refreshed. Unnecessary transfer should still be avoided so long as the E-Tag matches, and in the case it doesn't (or the browser doesn't handle the E-Tag), the {{index.html}} file is tiny enough that the overhead should be negligible (~4K).

The various other resources can then be safely cached, relying on invalidation of {{index.html}} to cause a cascading refresh.

> Control caching of extension JS/CSS
> -----------------------------------
>
>                 Key: GUACAMOLE-275
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-275
>             Project: Guacamole
>          Issue Type: Improvement
>          Components: guacamole
>            Reporter: Daryl Borth
>            Priority: Minor
>
> Guacamole combines the JS from extensions and rolls it into app.js. It then cache-busts by adding a version string to the app.js (eg: app.js?v=0.9.12-incubating). 
> This works great for preventing a browser from serving up JS from older Guacamole code. But it does nothing to prevent the code from older extensions from being loaded. We change our extension periodically and there isn't always a new Guacamole version out. This can lead to backwards-incompatible changes breaking the application.
> Can some sort of cache busting or expiration of some sort be added?
> Preferably, in the ResourceServlet there'd be some new headers added, eg: Cache-Control: no-cache or at least an Expires header



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)