I've been doing some research on versioned URLs (the current standard for Tapestry) vs. ETags.
The advantage of ETags is that we would no longer need to incorporate a version number into URLs, but could efficiently validate that the version of a file in the client browser's cache is up to date. The ETag could be just the md5 checksum of the contents of the server file; if the file contents have changed since the browser cached the content, then Tapestry sends the full content, including an updated ETag consisting of the MD5 checksum of the file contents. MD5 is fast and suitable for this purpose (but not for more demanding purposes, such as digital signatures). If the browser offers up the correct ETag then it has the right version and we respond with 304 (not modified). This is less efficient than our current approach; far-future expires header and a versioned url. With far-future/versioned the browser is informed that the file at that path will never change and can be cached aggressively, with no further requests to the server to see if there's been an update. With respect to yesterday's discussion of per-module version numbers: those would no longer be necessary with etags; the asset URL would be shorter, and would not incorporate any kind of version number. This would also make relative URLs (as sometimes used in CSS files) to be predictable. I think we're seeing a trade-off here: the versioned URL approach works well for infrequent, large-scale deployments. However, when one of those large-scale deployments occurs, then the cost is great: every connecting client will need to re-download every asset. With ETags; the cost of an incremental deployment is lower; most assets will not have changed; clients will requests the files, and be sent back a 304 if the file has not changed between deployments (regardless of whether the asset is part of the application, the Tapestry framework, or a third-party library). That means the server will receive more traffic, but will be sending inexpensive 304 responses much of the time. It is murky to me when the browser may decide to re-require an asset; this may take some experimentation. I'd hate to see applications where each page load is accompanied by a flurry of assets requests, all resulting in 304 responses. On the other hand, I'm also concerned about browsers running with mismatched assets, particularly, mismatched JavaScript libraries or modules. I suppose we could use the ETags approach, and use overrides of the the tapestry.asset-path-prefix symbol to change the asset URLs in a way that will force browsers to pull updates immediately. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
