I just wanted to point out a little interoperability issue with Apache, jammit, and gzipped assets.
With MultiViews turned on, I believe Apache will not serve any variants unless the requested file itself is not found. So if there is a common.css, for example, Apache will always serve it. I've found that only if I rename common.css to common.css.css, will Apache present the gzipped variant properly when common.css is requested.
Another option is to leave common.css and common.css.gz alone, but change the stylesheet link tag to refer to simply "/assets/common". This is more fragile than the first option, though, because when /assets/common is requested, Apache will serve the smaller of common.css and common.js if both files exist.
For now I've set my deploy scripts up to rename the files after jammit runs, but I thought I'd mention it here as well.
Thanks for mentioning it here ... Apache content-negotiation seems awful to work with when compared with the simplicity of Nginx's static-gzip module. Good luck with it.
I just wanted to point out a little interoperability issue with Apache, jammit, and gzipped assets.
With MultiViews turned on, I believe Apache will not serve any variants unless the requested file itself is not found. So if there is a common.css, for example, Apache will always serve it. I've found that only if I rename common.css to common.css.css, will Apache present the gzipped variant properly when common.css is requested.
Another option is to leave common.css and common.css.gz alone, but change the stylesheet link tag to refer to simply "/assets/common". This is more fragile than the first option, though, because when /assets/common is requested, Apache will serve the smaller of common.css and common.js if both files exist.
For now I've set my deploy scripts up to rename the files after jammit runs, but I thought I'd mention it here as well.