I agree with Bob and Dmitry. Not that ETags will increase the absolute number of requests but the issue is it won't reduce them. We should always use the far-future headers if we possible. Setting the application version is one of the easiest things you can do - I'd go as far as saying you are doing something wrong if you can't automatically increment the application version every time you are deploying.
Kalle 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 >
