On Tue, Mar 12, 2013 at 3:55 AM, Martin Grigorov <[email protected]>wrote:
> Hi, > > On Tue, Mar 12, 2013 at 11:31 AM, Bob Harner <[email protected]> wrote: > > > As a Tapestry user, I agree with your preference to prevent asset > > requests entirely rather than go the chattier ETag route. I would > > rather give up on the checksums-in-URLs idea (at least for modules) > > than have any significant increase in the number of requests to the > > server. > > > > I think Tapestry's far-future expires headers is one of its best > features. > Basically, in the future, all of Tapestry's asset handling will become more prominent. > > > > Exactly this combination will make the problems. > If some-bundle.css contains updates in the new version of the application > and the browser believes that it should not make a new request because of > the far-future header and the stable url then the user will not receive the > updates at all. > There's two scenarios here. #1 some-bundle.css changes between deployments In that case, the content hash for some-bundle.css will change, and thus the URL will change (as the content hash is part of the URL). #2 An image (or other asset) referenced from some-bundle.css changes This will be caught when url() constructs inside some-bundles.css are expanded. The target asset is located and its complete URL (including content hash) is substituted inside the url() construct. The content hash of some-bundle.css is computed on the version where URLs have been expanded (not the version on the disk); some-bundle.css will also be changed. The client will be directed to the new version of some-bundle.css, and from there to the new referenced asset. > By encoding the checksum in the url the browser will have to make the > request because for it this is a completely new resource without entry in > its caches. > > > > > > On Mon, Mar 11, 2013 at 4:35 PM, Howard Lewis Ship <[email protected]> > > wrote: > > > I've been working, a few hours a week, on getting per-asset checksums > > into > > > URLs. > > > > > > Some parts of this have been a challenge to accomplish without > completely > > > breaking the Asset interface and a bunch of public services. > > > > > > For ordinary assets, it's pretty easy ... but for aggregated JavaScript > > > libraries its been a pain that's affected a bunch of stuff. > > > > > > CSS files are now rewritten, since relative URLs will be broken by the > > > addition of the checksum. I have a first (but not final) pass at this, > > > where url() patterns in the CSS are converted into complete paths. This > > > also opens the door to CSS aggregation as well as JavaScript > aggregation. > > > > > > I still don't have a great solution for JavaScript modules; > RequireJS/AMD > > > expect that there's a common root folder name (such as > > "/assets/modules/"), > > > and module "a/b" is simply "*root*/a/b.js". For individual modules, you > > can > > > write your own overrides. In fact, Tapestry has to strip off the ".js' > > > part (which is hard-wired by RequireJS) because the actual server-side > > > resource could be CoffeeScript or some other language that compiles to > > > JavaScript. > > > > > > Short of iterating all server-side module files and writing a RequireJS > > > config for each one (mapping each name to a URL with an embedded > > checksum), > > > there isn't a great solution. Alternately, something could iterate all > > the > > > server-side modules and built a composite checksum, but there are at > > least > > > a couple of virtual modules generated at runtime (and locale specific > for > > > extra kicks). > > > > > > Modules may have to stay on the 5.3 approach: using the application > > version > > > number for everything. > > > > > > Finding the sweet spot where assets of all kinds (CSS, JavaScript > > > libraries, JavaScript modules, etc.) can be changed freely and the URLs > > > automatically reflect the actual content (that is, include a checksum > of > > > that content) for ideal client-side caching ... may simply be out of > > reach. > > > > > > Perhaps for modules we should use an alternate approach based on ETags > ( > > > http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there > would > > not > > > need to be any version number of checksum in a module URL, but clients > > > would request the module content more often (and based on ETag, would > > often > > > get a 304 Not Modified). I would prefer to see a URL that changes when > > the > > > content changes (which prevents the request entirely). > > > > > > -- > > > 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] > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> > -- 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
