>> BTW: The reason I'm asking is because that transparent shift from >> one app release to the next doesn't play along well with any caches >> (browser, caching proxies, CDNs etc.): When a shift to the next app >> release occurs, I generally need the client browsers to fetch a >> fresh copy of all files belonging to that release. And the only way >> to force them to do that is by having them use a different URL than >> for the old app release files.. > > Or, you could use proper proxy-friendly cache-control response headers > for those resources. Why aren't you doing that?
The OP's main thread here is asking about logical deployment. However as a sub-thread he is asking about caching. As Christopher replied in this thread, I will attempt to clarify what I think the OP is asking. If you have v1.0.0 of the app deployed, and it has sent cache for 1 day replies for javascript/image/css files, then this works fine. However as soon as you release the next version, the browsers won't send requests as they have a local cache. Christopher's reply was "use proper proxy-friendly cache-control response headers". IMO having the browser only query for such static resources as these daily is something that would be required to reduce calls. However this comes at the expense of causing this issue. My first thought was to suggest that the OP somehow use ETag header combined with a version number. However if the browser is told to cache for 1 day, this won't work. Having said that, if your app did send an ETag which was a hash of the files contents, then it would auto download a new version if it had changed between v1.0.0 and v1.0.1. I think that this leaves 3 solutions 1) Gauge what your site can support in terms of many calls to static resources vs when a new version is rolled out. Perhaps a 5 minute browser cache is ok. Or 60 mins. or 180 etc. It is a balancing act between reducing server calls for static content that hasn't changed and the time for an upgrade to appear in the browser 2) Adjust the source of the website such that each script/css/img tag contains a version number parameter. You could do this via pre-processing the source rather than manually. Then cache that for 365 days. If you release a new version, just update the number. 3) Set a cookie with the version number, and then redirect server side to different version specific urls. 2) seems to be the most robust to me. Christopher can you clarify what you meant? HTH Chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
