tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregor Schneider" <>
Subject Re: Securing Tomcat Article for Review
Date Wed, 10 Jan 2007 10:23:32 GMT
Hi Marcus,

On 1/10/07, Markus Schönhaber <> wrote:
> Gregor Schneider wrote:
> OTOH there a very good reasons to use a httpd-Tomcat combination. Alas,
> the "only reason" there "usually" is, as you said, I wouldn't count amongst
> the good reasons. Tomcat serves static content just fine. In combination with
> APR even finer.
I don't understand what you define as "just fine" and "finer",
however, we have a heavy-load web-app here that is accessed world-wide
with about 30.000 static html-pages plus some servlets. We conducted
tests with different load-runners and the results where quite clear:
We had an improvement Tomcat <-> Apache/Tomcat of about 20%.
To be fair, I have to say that we modified the headers within Apache
what we didn't when running Tomcat only. See, i believe in statistics
only when created by myself :)

>. I've read this claim ("httpd is superior for static content")
> many times, but I've never seen the one making that claim also providing
> facts that back up it's truth.

Well, if you don't consider the benchmarks we did here in our company
trustworthy (which I do understand), maybe you'd like to look at some
benchmarks on the Apache-website:

Summary of the charts in the last paragraph:

========= [snip] =============

For those who wonder "can tomcat handle static files?" My
opinion is yes. If you only have a single server co-located at an ISP
and can't afford a dedicated
image server, Tomcat will work just fine. For sites that need high
performance/high availability, the
best option is to setup dedicated Apache2 for the static files.

========= [snap] =============

> Of course, YMMV.

Right, and as I stated: Having a high-load-web-app with mostly static
content served, for us there was no other option after our own
performance-tests (BTW, we used JMeter and LoadRunner).

> Top of *my* list of good reasons for using httpd and Tomcat together is a
> httpd that acts as load-balancer for multiple Tomcat instances.
If you have limited ressources, that might be an option, in our case
that's just not enough and that's why we are using hardware-lb's.
> > that's definately not the case.
> "Definitely"? Hm, again such an absolute claim of yours for which you provide
> no facts to back it up.
As I stated above: I presume you *know* what you*re doing and you
*know* your ways around Tomcat and Apache httpd. That provided, again,
it is *definately* not the case that you decrease security, full stop.

> And he might think right. If you're adding complexity to the system you should
> be aware that there's the need to add even more sensible care to the system.
> If you fail to do that, the overall security will very propably be lower. As
> I see it, the chain of security is just as strong as it's weakest link.

See above: You have to know what you're doing. If you don't, get help
from a professional and get a security-audit. Although we *believe* to
know our ways round, we're doing both (hey, we're moving slowly back
to the topic... ;)
> My point is: one should worry about every piece of software installed. Even
> more so if it is accessible from an untrusted network. The more software, the
> more there is to worry about.
Agreed, however, usually there's a need to install a certain software.
I absolutely agree with you that, if you don't really need it, leave

> > OTOH, i'd rather have apache in
> > front than running tomcat on port 80 via jsvc or as a service.
> I'd like to repeat Chuck's question: why?
Plain and simple:

You also can misconfigure jsvc (ok, chances are pretty small...)

In *our* scenario I rather have Apache http in front because

- it performs better
- I got a lot of handy tools which either don't exists in Vanilla
Tomcat (like URL-rewriting, Header-modification etc.)
Sure, I could write my own filters and pass the static content through
them first, but that'd slow down the whole app (tested).


what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message