I agree with Bob, isn't the whole idea of asset checksums and far-future expire headers was to reduce number of HTTP requests?
Whats the advantage of ETags then? I bet the majority of assets for which HTTP 304 Not Modified would be returned would weight pretty much the same (in bytes) as returned 304 response. I'd normally use Etag when I had to implement some transactional state in some REST conversation. Keep in mind that, for instance, on AppEngine (or name any other cloud provider) such request could cost much more that just returning 304 -- AppEngine could start a new instance of application to serve this request. So I think for assets the main goal is reducing number of requests, but not optimizing the payload. Btw, > I've generally assumed that URLs with query > parameters are less likely to be cached in the browser, or served properly > by intermediate (reverse proxy) servers, but I haven't done the research. I noticed you've integrated checksums into the path of URL, not as GET parameters... Do you have any reason for this? Done any research? Because I'm seeing this pattern with GET parameters is widely abopted on the web and it works good. On Tue, Apr 9, 2013 at 5:43 AM, Bob Harner <bobhar...@gmail.com> wrote: > Doesn't the switch to ETags for modules make for much chattier web apps, > with lots more "conditional GET" requests for JS modules coming in after > every page request? > > In any case, good riddance to the application version numbers. > > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hls...@gmail.com> > wrote: > > > With the ETag support in place, there's no longer any need for the module > > asset URLs to have a checksum or version number; they are no longer > given a > > far-future expires header. > > > > URLs (by default) look like "/modules/t5/core/dom.js" (where the module > > name is t5/core/dom). > > > > The application version number is no longer used in any URLs; it now > exists > > just for documentation purposes (its written to the console at startup > and > > in the exception report). This is good news, because you could screw > > yourself by deploying your application and NOT changing the version > number > > (in 5.3.6). > > > > Very happy about this ... next up, thoughts on cometd/server-push > support? > > > > > > > > On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hls...@gmail.com > > >wrote: > > > > > > > > > > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gu...@gmail.com > > >wrote: > > > > > >> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hls...@gmail.com > > >> >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. > > >> > > > >> > > > >> It depends on where you put the checksum. > > >> If you put it as a GET parameter - then no relative URLs will be > broken. > > >> > > >> Have you read my blog post about Tapestry5 checksums in assets? > > >> > > >> > > > http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html > > > > > > > > > I'll read this shortly. I've generally assumed that URLs with query > > > parameters are less likely to be cached in the browser, or served > > properly > > > by intermediate (reverse proxy) servers, but I haven't done the > research. > > > > > > > > >> > > >> > > >> > 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 > > >> > > > >> > > >> > > >> > > >> -- > > >> Dmitry Gusev > > >> > > >> AnjLab Team > > >> http://anjlab.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 > > > > > > > > > > > -- > > 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 > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
