Browser caching GWT javascript app

[omsrobert]

We're using Tomcat 6.0.18 and GWT 1.5.3. The browser (Firefox 3 at
least) is caching our GWT application. Refreshing fixes it but that's
not an option for production. I would think this is a common issue.
How do we fix it? Write a response header filter for Tomcat or is
there a better way?

Here's the HTTP headers:

http://ourserver/mywebapp/home/com.mycompany.mine.OurGWTApp.nocache.js

GET /mywebapp/home/com.mycompany.mine.OurGWTApp.nocache.js HTTP/1.1
Host: ourserver
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Accept: */*
Accept-Language: en-us,en;q=0.7,ja;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://ourserver/mywebapp/theapp/apphome.html
Cookie: JSESSIONID=621F38E17EF1599EEF41F5AB43A820EE; CP=*
X-lori-time-1: 1229109488064
If-Modified-Since: Fri, 12 Dec 2008 18:31:55 GMT
If-None-Match: W/"5830-1229106715375"
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Server: Apache-Coyote/1.1
Etag: W/"5830-1229106715375"
Date: Fri, 12 Dec 2008 19:18:07 GMT

[Shawn Pearce]

Near as I can tell, the browser and server are working correctly.

The browser sent a request along with the data it has in cache; the server responded with a 304 Not Modified, letting the browser know that its cached copy is still current.  Thus the server can save time and bandwidth by not resending content the browser already has.

If you deploy a new version of the application, the client still should have validated the content, but the server would have sent back a 200 response with the new version, holding a different ETag and a different Last-Modified date.

[Thomas Broyer]

On 12 déc, 20:35, omsrobert <robert.lafe...@o-ms.com> wrote:
> We're using Tomcat 6.0.18 and GWT 1.5.3.  The browser (Firefox 3 at
> least) is caching our GWT application. Refreshing fixes it but that's
> not an option for production.  I would think this is a common issue.
> How do we fix it?  Write a response header filter for Tomcat or is
> there a better way?
>
> Here's the HTTP headers:
>
> http://ourserver/mywebapp/home/com.mycompany.mine.OurGWTApp.nocache.js

You should configure your server to send very short expiration for
*.nocache.* (something like 2 minutes) and very long expiration for
*.cache.* (RFC2616 recommends 1 year to indicate a resource is
"permanently cacheable")

BTW, it all depends how your server is computing the ETag. I'd
recommend disabling ETags altogether.

[omsrobert]

Does anyone have a sample config snippet for Tomcat?