Bug 875814 - Use appropriate caching policy for GWT application resources
Use appropriate caching policy for GWT application resources
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
Unspecified Unspecified
urgent Severity unspecified
: ---
: 3.2.0
Assigned To: Alexander Wels
Jiri Belka
: Improvement
Depends On:
Blocks: 948448
  Show dependency treegraph
Reported: 2012-11-12 10:42 EST by vszocs
Modified: 2015-09-22 09 EDT (History)
9 users (show)

See Also:
Fixed In Version: sf11
Doc Type: Enhancement
Doc Text:
Certain GWT application resources did not have the appropriate caching headers applied due to Apache or JBoss configuration issues. Consequently, the browser could not cache resources that rarely (if ever) changed, and had to request them from the server each time the page was loaded. The proper caching policy is now defined in both the Apache and JBoss configuration, so the browser can properly cache the necessary resources, which results in fewer requests to the server.
Story Points: ---
Clone Of:
Last Closed: 2013-06-10 17:19:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 10449 None None None Never

  None (edit)
Description vszocs 2012-11-12 10:42:48 EST
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
Comment 2 Alexander Wels 2012-12-28 11:59:19 EST
Code available here:
Comment 3 Einav Cohen 2013-01-02 21:49:19 EST
(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...)?
Comment 4 Alexander Wels 2013-01-03 08:18:03 EST
(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:
Comment 9 vszocs 2013-03-14 13:14:17 EDT
rhev-3.2 patch verified on local development environment.
Comment 10 Jiri Belka 2013-04-03 04:10:17 EDT
OK, sf12, tested with Firebug.
Comment 11 Itamar Heim 2013-04-25 17:44:16 EDT
any difference in load time after closing-opening the browser due to the caching?
Comment 12 Jiri Belka 2013-04-30 09:34:21 EDT
I don't see any big difference.
Comment 15 errata-xmlrpc 2013-06-10 17:19:50 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.