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. 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]
