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/
