Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 875814

Summary:	Use appropriate caching policy for GWT application resources
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Vojtech Szocs <vszocs>
Component:	ovirt-engine-webadmin-portal	Assignee:	Alexander Wels <awels>
Status:	CLOSED ERRATA	QA Contact:	Jiri Belka <jbelka>
Severity:	unspecified	Docs Contact:
Priority:	urgent
Version:	3.2.0	CC:	acathrow, awels, dyasny, ecohen, iheim, mgoldboi, Rhev-m-bugs, sgrinber, ykaul
Target Milestone:	---	Keywords:	Improvement
Target Release:	3.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
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:		Environment:
Last Closed:	2013-06-10 21:19:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	948448

Description Vojtech Szocs 2012-11-12 15:42:48 UTC

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 16:59:19 UTC

Code available here:
https://bugzilla.redhat.com/show_bug.cgi?id=875814

Comment 3 Einav Cohen 2013-01-03 02:49:19 UTC

(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 13:18:03 UTC

(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

Comment 9 Vojtech Szocs 2013-03-14 17:14:17 UTC

rhev-3.2 patch verified on local development environment.

Comment 10 Jiri Belka 2013-04-03 08:10:17 UTC

OK, sf12, tested with Firebug.

Comment 11 Itamar Heim 2013-04-25 21:44:16 UTC

any difference in load time after closing-opening the browser due to the caching?

Comment 12 Jiri Belka 2013-04-30 13:34:21 UTC

I don't see any big difference.

Comment 15 errata-xmlrpc 2013-06-10 21:19:50 UTC

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