Thanks to everyone that responded. I'll make a few comments.
DOJO tends to make a million calls for images/scripts/css files. The ETag solution isn't going to optimize well because there will still be a ton of 304 requests which all take time to make happen. Also, I'm not using Apache in front of tomcat. I'm using Tomcat bare. Besides, let's face it. If the browser were doing the right thing then they would pick up that the script file changed using the last_modified header that tomcat presents. The problem is that the browsers are just using the cached version rather than making an if-modified-since request. The .js?arg=someval option is a pretty reasonable idea. It offers the advantage that I don't have to do hocus-pocus with my scripts path name. The problem I'm seeing here though is that with something like the dojo library which makes its own internal calls to load child javascript files it won't work. For example, dojo loads the dijit files including dijit/_Dialog.js. There's no way to attach the argument to the dojo request into the dijit directory. So, I think this is a fragile solution. My previous best plan was to rename my scripts directory to scripts-x.x.x. The downside of the scripts-x.x.x is that when I upgrade my customers, I've got to make the old scripts-x.x.x directory go away. I'll also have to do some hocus pocus to make CVS, the version control system OK with it. Perhaps I can just make scripts a symlink to scripts-x.x.x and keep it happy that way. The other big problem I see is that if I make the dir name change on every build, then even the tiniest of changes will force me to rename the directory. I run a hosted application and this would have to be done across hundreds of deployments. The rewrite solution is OK. It solves the problems but adds another component to my request cycle, and to my distribution load. On the other hand, it doesn't have the icky problem of needing to rename the directory every time I push out a trivial change. The other advantage I see is that using this, I can set arbitrarily long expires headers on my responses so that the browser "should" only request files when the program version changes. This is probably the solution I should go with. Again, thanks to everyone who responded. George Sexton MH Software, Inc. 303 438-9585 www.mhsoftware.com > -----Original Message----- > From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com] > Sent: Tuesday, April 12, 2011 1:06 PM > To: users@tomcat.apache.org > Subject: Re: OT: Versioning in Javascript Files > > Chris, > > >> href="some.css?v=${parameter}" > > > > Some clients and proxies will refuse to cache resources with a query > > string. In those cases, caching (obviously) won't work and there > might > > be a significant loss in performance of the web site. > > Exactly. I tested on one usecase (no proxy, limited number of web > browsers), which is not representative. Now I see that it should not be > used as a general solution. > > -Ognjen > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
