[
https://issues.apache.org/jira/browse/GUACAMOLE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16214661#comment-16214661
]
Michael Jumper commented on GUACAMOLE-275:
------------------------------------------
Disabling caching entirely, such as with "Cache-Control: no-cache", is
definitely not an option. Adding an "Expires" header would mitigate things, but
not necessarily solve them, as there would always be the chance that a new
version of an extension could be deployed prior to cache expiration.
It should be possible to tie the caching of JS and CSS into the current version
of that dynamically-generated resource (using a checksum rather than the
version number, for example), but doing so would require filtering of
{{index.html}} within the web application at runtime rather than during the
build.
> 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
(v6.4.14#64029)
