So it's looking to me as if we should be doing the following: - analyze the request *at render time* to see if gzip encoding is supported - generate different URLs depending on whether gzip encoding is enabled for the request and *appropriate to the asset type* - compute the checksum for gzip'ed assets on the gzip stream, not the uncompressed stream - handle the module URL the same way
I would propose /assets/... for uncompressed assets /assets.gz/... for compressed assets /modules/... for uncompressed modules /modules.gz/... for compressed modules I also like the idea of allowing a special checksum in the URL that defeats the the normal checksum check ... but only for context assets, or assets under /META-INF/ (for security reasons). I think these changes would address the problems Barry has identified. On Tue, Apr 9, 2013 at 11:43 AM, Howard Lewis Ship <[email protected]> wrote: > > > > On Tue, Apr 9, 2013 at 9:57 AM, Barry Books <[email protected]> wrote: > >> When I tried to integrate the Amazon CDN with Tapestry the version in the >> URL was a constant problem. The other issue is the zipped vs unzipped >> assets. Tapestry uses the same URL for both but you can't do that with >> Amazons CDN. You need two files. > > > Interesting. That's something that could be addressed, it just > never occurred to me that it was a problem. It's a pain though ... it means > that anytime we write an Asset URL that *could* be compressed (JavaScript, > CSS ... but not images) then we have to decide whether to write the URL for > the compressed version or the uncompressed version. > > In the current implementation, we make that decision based on the request > that asks for the asset, and send back the normal or compressed content at > that point. > > >> This will also be a problem with caching by ETag since compressed and >> uncompressed assets will have different ETags. I think processing the CSS >> is likely to also cause CDN problems. >> > > Currently, we use the same ETag for both the compressed and the > uncompressed version. I can see that this may be an issue with regards to > caching and CDN ... a client may request the uncompressed version and get a > GZIP stream unexpectedly. > > GWT uses the hash in asset urls and it seems to work fine. It also used >> nocache in the URL to specify the URL is not cached. This can be useful >> under some circumstances. >> > > I can see that as well. > > >> >> On Apr 9, 2013, at 11:37 AM, Howard Lewis Ship <[email protected]> wrote: >> >> > In 5.4-alpha-3, Tapestry parsers CSS and converts url() references into >> > absolute paths that include the asset checksum. >> > >> > There may also be the option to inline small assets directly into the >> > stylesheet. >> > >> > >> > On Tue, Apr 9, 2013 at 6:26 AM, Barry Books <[email protected]> wrote: >> > >> >> After being bitten by APPLICATION_VERSION I switched to this >> >> >> >> configuration.override(SymbolConstants.APPLICATION_VERSION, >> >> *new*Date().getTime()); >> >> >> >> >> >> This way on my development machine I get a new version every restart >> and on >> >> my production machine on every deploy. >> >> >> >> >> >> That said I think the hash of the object in the URL and a never expires >> >> header is the way to handle this. The only problem I can think of is >> assets >> >> in style sheets. I would say the solution to that problem lookup the >> asset >> >> with the hashed url and return the object with a never expires header. >> If >> >> there is no hash just return the object without the header. This makes >> it >> >> easy to use assets in stylesheets. If you want to solve the caching >> problem >> >> just override (or declare) the style in the Layout component and use >> the >> >> asset like this: >> >> >> >> >> >> <style> >> >> >> >> .navbar-fixed-top { >> >> >> >> xheight: 64px; >> >> >> >> background-position: 0px 40px; >> >> >> >> xbackground-image: url('${context:/images/top-background.jpg}'); >> >> >> >> xbackground-repeat: repeat-x; >> >> >> >> } >> >> >> >> </style> >> > >> > >> > >> > -- >> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > 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
