-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chris,
On 7/21/15 1:30 PM, chris derham wrote: >>> 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. Of course. > 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. The ETag won't help if the browser is convinced that the resource should not go stale in the next e.g. 24 hours: the browser won't even make a HEAD request for that resource, or a conditional-GET with an If-Last-Modified header set. The user would have to do a full-refresh (usually SHIFT-CTRL-R or equivalent) to re-check the ancillary files e.g. .css, .js, etc. > 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. This is probably the best way to deal with files that have a true "version" to them: once you sundown one version, you create a new URL for the new version, etc. But for things like .css, I think it's probably not necessary. We have some GWT-based components where the version number of the .js files is very important, and the browser can't just use the old version of the script with new data and vice-versa. So we do version those URLs, but it's not done at the context-path level.. it's done at the resource level. So, something like this: /context/path/to/js/my-awesome-tool.1.4.2.js Then this doesn't even have anything to do with the current version(s) available in parallel deployment. It also means that it will work if you want to offload your static files to another server that knows nothing about parallel deployment. > 3) Set a cookie with the version number, and then redirect server > side to different version specific urls. Yuck. > 2) seems to be the most robust to me. Christopher can you clarify > what you meant? I agree that #2 is probably best, but it depends on the circumstances. - From what I've read here, I'd stick with #2. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrqaeAAoJEBzwKT+lPKRYQxAQAJS/JImeo2FVFi7qwavqnTXb MZJfxSBIJsGNaWryTdGo0MtVXN2vCcvL3Wnhsa71Vp80g5iyUs5Wc2GBMgTRr4fQ mYMMST3c2yu1TZl1kGa91d86eBFzBwEKp1Qb12/GI7iDTArtwHpkVWhNErVvheex dHQcMzWTfcsRzxYBHtWGTXlyd+JtsRdjOPooykTznsRslQuQFvwFMVUyBHEAWmba XH9Wu2SK3SdTjsAdyXgYQYuqryEKts5SFV6zfkXoK9P8Z3nt/vZGZlHJJj0fcq/I KY6gQeoNfs3JaGqwYJ2NAlr3oduziSB5aC1FuP5mPupQ/dsXGsx9a3WKOTnAL+XU cSRMS41BSU3oWq40CwbqRhZ1/iDzmq0A5VypMTHobABflHPY48DzEZxzAHyb0Pms B0iJ5IwHhdoaHcvyyTdx+LXfD6pIf+eKc8GIBqRYpZf1fFyQtNTpvJjjkSNxHPTW Am+rHUDI5Z2tBEYOdkmrHm80hCfG6v6My/zv9BuDxY90CBGHwIv6BkKLRWDD0MAe 8vrgPwUy+xbBFwRmli3UnVd77XE7DKw2o3Q+VCVMnUm7mwLEY2+QtvCP8nESloBp 53vgfxNUCBr4QnX7FSpIjey38uHgIIbPwA9pZGWeW6dhfVLU1bE1P8muJldU4Zni iZjdXgDNB0GOssdI3EEv =55bt -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
