P.S., for production app, some or all modules should be aggregated into the JavaScriptStack. I haven't implemented that, yet.
On Wed, Jun 5, 2013 at 11:35 AM, Howard Lewis Ship <hls...@gmail.com> wrote: > BTW, the new Cache-Control header seems to do the exact trick we need. > > > On Wed, Jun 5, 2013 at 11:34 AM, Howard Lewis Ship <hls...@gmail.com>wrote: > >> >> >> >> On Wed, Jun 5, 2013 at 4:11 AM, Barry Books <trs...@gmail.com> wrote: >> >>> If the goal if to have the browser cache the asset and only do a new >>> request when the asset changes I think the only reliable way to >>> accomplish >>> this is by setting the expires header and changing the url when the asset >>> changes. This way the browser has no choice but to do the right thing. >>> >>> What's the rational for treating module URLs differently than assets? >>> >>> >> Please see the archives; this has been discussed. Summary: modules are >> loaded by name, knowing only the name. Short of locating every possible >> module (actually, not possible; some modules are virtual ... created on the >> fly from other data) and computing its code and writing a special path for >> each one, there's no way to embed the version number in the module URL. >> >> >>> >>> On Wed, Jun 5, 2013 at 4:04 AM, Massimo Lusetti <mluse...@gmail.com> >>> wrote: >>> >>> > On Wed, Jun 5, 2013 at 1:09 AM, Howard Lewis Ship <hls...@gmail.com> >>> > wrote: >>> > >>> > I believe that if we add a "Cache-Control: must-revalidate" to module >>> > > content responses it should work as expected. >>> > > >>> > >>> > >>> > BTW I've always had problems with cache and cache headers, anyway, at >>> > w3c[1] it clearly states that the cache-control header must be honored >>> by >>> > all caching mechanism in the chain serving a http request but if you >>> go at >>> > "must-revalidate"[2] it says that it must be revalidated when it >>> becomes >>> > stale so it has to become stale (expires or max-age) before the cache >>> must >>> > obey to that header. >>> > >>> > >>> > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html >>> > [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 >>> > >>> > -- >>> > Massimo Lusetti >>> > >>> >> >> >> >> -- >> 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 > -- 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
