From reading Howard's post about the trade offs I see why far-future expirations would be a better performing variant. I like bob's suggestion of just using the md5 instead of a version number to keep track of assets. This way thre is no version matching or hackers.
On Jul 23, 2012, at 9:03 PM, Bob Harner <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
