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/