I'm not sure that the browsers will cache resources with parameters as aggressively as those with just path. I could be wrong.
To me, putting the checksum into the URL as a parameter is something of a hack that's done because there isn't the same infrastructure that Tapestry has for building and dispatching the URLs. The theory of the ETags is that another server, such as the firewall proxy, could cache the files at that layer, and prevent the request from moving inwards to the servlet container at all. If we incorporate the checksum into the module URL (even as a GET parameter), it will require Tapestry to locate every possible module (including "virtual" modules that are generated at runtime) and write a large block of JSON mapping each module to its corresponding URL. That's just how AMD operates. On Tue, Apr 9, 2013 at 12:21 AM, Dmitry Gusev <[email protected]>wrote: > 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected] > > > >wrote: > > > > > > > > > > > > > > > On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev < > [email protected] > > > >wrote: > > > > > > > >> On Tue, Mar 12, 2013 at 12:35 AM, 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. > > > >> > > > > >> > > > > >> 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 > -- 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
