By Duncan Mills on Mar 07, 2012
There was some debate in the Hudson Community meeting this week on various areas of performance that need to be addressed for enterprise grade installations such as that used at the Eclipse foundation. Least of these issues was a problem that we'd observed both on ci.hudson-ci.org server and other, and this was the matter of image and other resource caching, or rather, lack thereof. Hudson itself has a filter which sets the expire header on all of these resources to a year in the future, so the browser should be retrieving from cache rather than hitting the server again. However, this simply was not happening.
An investigation of the traffic via Chrome's developer tools shows the cause:
You can see that the Expires directive in the response is 2013, however, the Cache-Control: no-cache is overriding this.
It turns out that this is down to Tomcat behaviour when running a secured web app. It sets the no-cache directive automatically, irrespective of the type of resource it is serving. Fortunately there is a way to prevent this behaviour using a simple configuration in the Tomcat server.xml, simply add the following Valve definition into the <Context> being used for Hudson:
<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" disableProxyCaching="false" />
Once Tomcat is restarted, your resources will be cache-able again. For more complete information about Hudson configuration behind Tomcat check out the Tomcat page in the Hudson Wiki.