According to [1], we should enforce appropriate caching policy for key GWT application resources. Preferably, this should be done on JBoss AS level, e.g. through a custom servlet filter in "frontend" UI module (frontend/webadmin/modules/frontend). The implementation should also prefer HTTP/1.1 "Cache-Control" header [2]. a, Resources intended to be cached forever on the client This includes: - module permutations <md5>.cache.html - ClientBundle composite images <md5>.cache.png / <md5>.cache.gif - split points deferredjs/<md5>/<n>.cache.js For such resources: - the client doesn't need to ask server if the content has changed - use "Cache-Control: max-age=31556926" (Representations may be cached by any cache. The cached representation is to be considered fresh for 1 year.) - testing: ensure that the resource is not requested again from server, after being cached for the first time b, Resources which always need to be checked for changes This includes: - permutation selector script <applicationName>.nocache.js - application host page WebAdmin.html/UserPortal.html (dynamic host page servlet) For such resources: - the client can cache the resource, but must always ask server if the content has changed - use "Cache-Control: no-cache" (Representations are allowed to be cached by any cache. But caches must submit the request to the origin server for validation before releasing a cached copy.) - testing: ensure that the resource is always requested from server, with server responding either 304 (resource not modified) or 200 (new version of resource) - testing: ensure that response ETag header is set appropriately by the server c, Resources not intended to be cached on the client at all This includes: - GWT RPC calls (Generic API servlet) - REST API calls [note: related to caching, but not related to GWT for the moment, maybe should be done in future] For such resources: - the client must never cache the resource, must always ask server to get its content - use "Cache-Control: no-store" (Caches must not cache the representation under any condition.) - testing: ensure that the resource is always requested from server, even if the content didn't change [1] https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#public_resources [2] http://stackoverflow.com/questions/2970938/ideal-http-cache-control-headers-for-different-types-of-resources
Code available here: https://bugzilla.redhat.com/show_bug.cgi?id=875814
(In reply to comment #2) > Code available here: > https://bugzilla.redhat.com/show_bug.cgi?id=875814 Alex, any chance that you meant to put here a link to gerrit (rather than a link to this BZ...)?
(In reply to comment #2) > Code available here: > https://bugzilla.redhat.com/show_bug.cgi?id=875814 Yes, I did mean to put in the link to gerrit which is here: http://gerrit.ovirt.org/#/c/10449
rhev-3.2 patch verified on local development environment.
OK, sf12, tested with Firebug.
any difference in load time after closing-opening the browser due to the caching?
I don't see any big difference.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0888.html