I had to bolt on an input servlet filter to tomcat once. To do this I had to write the servlet filter code and then add <filter> and <filter-mapping> tags to the application WEB-INF/web.xml file. -James
-----Original Message----- From: Tim Watts [mailto:t...@dionic.net] Sent: Thursday, July 14, 2011 8:12 AM To: mod_perl list Subject: Re: mod_perl output filter and mod_proxy, mod_cache On 14/07/11 12:43, André Warnier wrote: > Hi. > > I have to apologise. > I misunderstood your first post, and I wanted to verify on the Tomcat > list, so I quoted the following passage of your first post in my message > there : > > "Sadly, the tomcat dev's forgot to set any caching headers in the HTTP > response (either Expires, Last-Modified or Cache-control) so the sites > are largely uncacheable by browsers and the various tomcats are becoming > overloaded." > > Unfortunately, the Tomcat Dev's there took it rather seriously, and as a > consequence now you name is shit on the Tomcat list. > > > .. just kidding, I did not quote your name. LoL - I hate tomcat anyway (for it's fatness) so I don't mind if they hate me ;-> I should have clarified as "my Department's dev team" (ie the ones who use tomcat here) rather than the Tomcat Developers themselves... I have no doubts that jsp can be told to emit certain headers but for some reason a lot of web developers IME often miss the finer points of HTTP. This of course would be the correct place to do it as they can choose different max-age times to suit the content. I plan to run a 20 minute seminar on this specific point for my lot (and more such seminars for other issues like security and SQL efficiency) but that still leaves loads of old black-boxes to manage for a few years. > Anyway, apart from a few huffed responses to my misquote (since then > rectified), someone provided a suggestion that may not be the simplest, > but might be helpful anyway in some cases : > > Have a look at : http://www.tuckey.org/urlrewrite/ > > This is a "Java Servlet Filter", which can be added transparently > "around" any Tomcat web application (by adding the required section in > the web.xml config file of that web application). > Java Servlet Filters are such that the Tomcat web application is not > even aware that it is there, and continues to work as before. Much like > Apache input and output filters in fact, except that a Java Servlet > Filter is both at the same time (it "wraps" the webapp on both sides). That could be interesting too - as long as it's something I can bolt in without having to recompile the webapp code, I'm game. As a linux sysadmin, I draw a clear line between the systems (my problem) and the apps (dev team) - and not knowing java (much) I'm not qualified to mess with their stuff... I'm happy to go as far as messing with server.xml and web.xml though :) > Anyway, this filter can do such things as conditionally or not adding > response headers to anything the webapp produces. And it can do much > more, as with time it has evolved into some kind of mish-mash of > mod_rewrite, mod_headers and mod_proxy. > > It is more one-by-one work than doing something at the Apache front-end > level or via a proxy, but it also provides better fine-tuning > possibilities. > So, if you can for instance easily identify the worst offenders, it > might be an option. > > And it is certainly a good tool to have in one's toolcase. I agree - I'll have a look at that after I play with Alex's suggestion of Varnish :) Thanks very much for your time :) all the best, Tim -- Tim Watts Personal Blog: http://www.dionic.net/tim/ IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE: This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
