You can reference every static content with: /js/site.js?version=<timestamp>
If using Maven or Ant, in the building process generate a timestamp and substitute it wherever applicable. On Thu, Feb 10, 2011 at 3:56 PM, Greg Lindholm <greg.lindh...@gmail.com> wrote: > I'm trying to find out what are the "Best Practices" and if there are > any utilities available to assist with versioning of static resources > and cache-control. > > I'm working on an application (written with Struts 2) that uses a > filter to apply cache-control headers to the static resources, > javascript, css, and image files. > > The problem is we are having frequent releases to production and > user's browser's will have cached previous versions of the 'static' > resources. Now it is possible for the developers to manually add a > version number to each static resource file and update that version > number before each release but that would be a very fragile and error > prone procedure. To mitigate the problem we have turned down the > cache-control down to 1 hour but his is still far from ideal and only > helps if the browsers obey the max-age setting. > > So what are the "Best Practices" and are there any utilities to assist? > > Here is the scheme I was considering building: > > Use tags to generate the static resource paths so they will include a > release number in the path. > So instead of path "/js/site.js" as in this script tag: > <script type="text/javascript" src="/js/site.js"></script> > I would generate this with the path "/v1.2.3/js/site.js" where > "/v1.2.3/" represents the release number: > <script type="text/javascript" src="/v1.2.3/js/site.js"></script> > > I would also write a Filter that would look for requests starting with > the "/v1.2.3/" release number. When it found one it would strip off > the release from the path and forward it to the actual path and on > return it would apply the cache-control headers. > > I think this would handle the cache-control problem as the browsers > would cache using the path with the release version and this would > change with each new release. > > Do any utilities like this exist already? (no need to reinvent the > wheel if they do.) > > Greg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
