tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: Coming soon: per-Asset checkums in URLs
Date Tue, 12 Mar 2013 10:55:12 GMT
Hi,

On Tue, Mar 12, 2013 at 11:31 AM, Bob Harner <bobharner@gmail.com> 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.
>

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.
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 <hlship@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.
> >
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message