I believe most Tapestry applications are deployed infrequently enough that the current far-future-expires mechanism is the better approach, at least as the default. I really love how lightweight (in terms of number of requests) my Tapestry apps have been compared with other frameworks I have used.
On the other hand, if Tapestry could generate the asset version number automatically (from an md5 checksum), that'd be even better, although I'm sure I'm not seeing all of the implications of that. On Mon, Jul 23, 2012 at 8:19 PM, Howard Lewis Ship <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
