OT static resources, cache control, and versioning

[Greg Lindholm <gr...@gmail.com>]

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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: OT static resources, cache control, and versioning

[Maurizio Cucchiara <ma...@gmail.com>]

I remember I wrote a simple filter coupled with a *jsp* (not a struts)
tag library.
As far as I can remember the tag library worked as resource assembler
for instance:
<t:scripts>
   <t:script src="...FIRST_CUSTOM_JS.js"/>
   <t:script src="...SECOND_CUSTOM_JS.js"/>
</t:scripts>

So in this specific case the tag library combines this two file in
just one and generates a digest based on the output content. After if
the file doesn't exist tries to write its content in a temporary
directory for instance: /tmp/c6e2e39e982b80529bdba79139aeb4e.js.
Later the servlet filter intercepts the request URL and, if it matches
the resource name,  sends the file content.

In this way you can send the content to the browser with a "never
expire" header.


On 10 February 2011 15:56, Greg Lindholm <gr...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>



-- 
Maurizio Cucchiara

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: OT static resources, cache control, and versioning

[Jordi Fernández <jo...@esilog.com>]

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 <gr...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org