tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Coming soon: per-Asset checkums in URLs
Date Tue, 12 Mar 2013 18:08:25 GMT
On Tue, Mar 12, 2013 at 3:55 AM, Martin Grigorov <mgrigorov@apache.org>wrote:

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

Basically, in the future, all of Tapestry's asset handling will become more
prominent.


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

There's two scenarios here.

#1 some-bundle.css changes between deployments

In that case, the content hash for some-bundle.css will change, and thus
the URL will change (as the content hash is part of the URL).

#2 An image (or other asset) referenced from some-bundle.css changes

This will be caught when url() constructs inside some-bundles.css are
expanded.  The target asset is located and its complete URL (including
content hash) is substituted inside the url() construct.

The content hash of some-bundle.css is computed on the version where URLs
have been expanded (not the version on the disk); some-bundle.css will also
be changed.

The client will be directed to the new version of some-bundle.css, and from
there to the new referenced asset.


> 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/>
>



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

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