Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

Versioning Static Assets with UrlRewriteFilter

  • submit to reddit

A few weeks ago, a co-worker sent me interesting email after talking with the Zoompf CEO at JSConf.

One interesting tip mentioned was how we querystring the version on our scripts and css. Apparently this doesn't always cache the way we expected it would (some proxies will never cache an asset if it has a querystring). The recommendation is to rev the filename itself.

This article explains how we implemented a "cache busting" system in our application with Maven and the UrlRewriteFilter. We originally used querystring in our implementation, but switched to filenames after reading Souders' recommendation. That part was figured out by my esteemed colleague Noah Paci.

Our Requirements

  • Make the URL include a version number for each static asset URL (JS, CSS and SWF) that serves to expire a client's cache of the asset.
  • Insert the version number into the application so the version number can be included in the URL.
  • Use a random version number when in development mode (based on running without a packaged war) so that developers will not need to clear their browser cache when making changes to static resources. The random version number should match the production version number formats which is currently: x.y-SNAPSHOT-revisionNumber
  • When running in production, the version number/cachebust is computed once (when a Filter is initialized). In development, a new cachebust is computed on each request.

In our app, we're using Maven, Spring and JSP, but the latter two don't really matter for the purposes of this discussion.

Implementation Steps
1. First we added the buildnumber-maven-plugin to our project's pom.xml so the build number is calculated from SVN.


2. Next we used the maven-war-plugin to add these values to our WAR's MANIFEST.MF file.


3. Then we configured a Filter to read the values from this file on startup. If this file doesn't exist, a default version number of "1.0-SNAPSHOT-{random}" is used. Otherwise, the version is calculated as ${project.version}-${buildNumber}.

private String buildNumber = null;

public void initFilterBean() throws ServletException {
try {
InputStream is =
if (is == null) {
log.warn("META-INF/MANIFEST.MF not found.");
} else {
Manifest mf = new Manifest();;
Attributes atts = mf.getMainAttributes();
buildNumber = atts.getValue("Implementation-Version") + "-" + atts.getValue("Implementation-Build");"Application version set to: " + buildNumber);
} catch (IOException e) {
log.error("I/O Exception reading manifest: " + e.getMessage());


// If there was a build number defined in the war, then use it for
// the cache buster. Otherwise, assume we are in development mode
// and use a random cache buster so developers don't have to clear
// their browswer cache.
requestVars.put("cachebust", buildNumber != null ? buildNumber : "1.0-SNAPSHOT-" + new Random().nextInt(100000));

4. We then used the "cachebust" variable and appended it to static asset URLs as indicated below.

<c:set var="version" scope="request" 
<c:set var="base" scope="request"

<link rel="stylesheet" type="text/css"
href="${base}/v/${version}/assets/css/style.css" media="all"/>

<script type="text/javascript"

The injection of /v/[CACHEBUSTINGSTRING]/(assets|compressed) eventually has to map back to the actual asset (that does not include the two first elements of the URI). The application must remove these two elements to map back to the actual asset. To do this, we use the UrlRewriteFilter. The UrlRewriteFilter is used (instead of Apache's mod_rewrite) so when developers run locally (using mvn jetty:run) they don't have to configure Apache.

5. In our application, "/compressed/" is mapped to wro4j's WroFilter. In order to get UrlRewriteFilter and WroFilter to work with this setup, the WroFilter has to accept FORWARD and REQUEST dispatchers.



Once this was configured, we added the following rules to our urlrewrite.xml to allow rewriting of any assets or compressed resource request back to its "correct" URL.

<rule match-type="regex">
<rule match-type="regex">

Of course, you can also do this in Apache. This is what it might look like in your vhost.d file:

RewriteEngine    on
RewriteLogLevel  0!
RewriteLog       /srv/log/apache22/app_rewrite_log
RewriteRule      ^/v/[.A-Za-z0-9_-]+/assets/(.*) /assets/$1 [PT]
RewriteRule      ^/v/[.A-Za-z0-9_-]+/compressed/(.*) /compressed/$1 [PT]
Whether it's a good idea to implement this in Apache or using the UrlRewriteFilter is up for debate. If we're able to do this with the UrlRewriteFilter, the benefit of doing this at all in Apache is questionable, especially since it creates a duplicate of code.



Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Thomas Eichberger replied on Sun, 2010/06/06 - 1:26pm

Thanks for this hint. Sounds interesting. I'll give it a try.

Michael Eric replied on Wed, 2012/09/26 - 3:45pm

Nice post.

Of course, this is the only way to go when the versioning is not an optional requirement, but I am curious if setting of ETag headers wouldn't solve your problem related to asset caching?

I'm not sure what wro4j version are you using, but the latest one (1.2.7 and even earlier ones) updates ETag header based on the last update time of the assets. From my experience, it solves the asset caching problem for all the browsers and doesn't require any extra configurations.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.