> > Maybe your idea of making this be a HTTP 1.0 request, or say set > whatever internal flag Tomcat would itself set if it had been an HTTP > 1.0 request. Perhaps a servlet filter is soon enough, or if not, a > <Valve>. > Provided that would do the trick, it is also something you could do at > the Apache level, before proxying to Tomcat. > I am wondering about possible side-effects though. The chunked > encoding > is probably not the only difference between 1.0 and 1.1. For example, > if > your Tomcat has Virtual Hosts, it may be an issue. >
Yeah, I do have a VH in additional to the normal localhost, I'll have to test that out with the 1.0 connection. > Now, maybe another stupid question : do you /have/ to generate these > javascripts with Tomcat ? Couldn't your front-end generate them by > itself ? > Well, they used to be static JS files, then we decide we wanted more flexibility in the content that went into them, so we stuck them in a database and decided to generate them as needed. But you know, you make something better it some ways, you make it worse in others, and while moving it to tomcat make it better on the front-end, on the back-end it kind of hurts me in performance and simplicity. So the short answers are no and yes, respectively..but it's not likely to happen. It's amazing how complicated things get when you start caching and compressing stuff. It all seems like an easy thing to do. Turn on a couple apache modules, parameters, and off you go. But oh wait, this old browser doesn't support compression, and shit, my CDN needs this header, and I got a cache at the CDN, and a cache in my apache which creates a zillion cache files for one real file because I got a Vary header, and then the cache in tomcat, and really how long do I have to wait for content to be fresh, and and.. -Tony
