tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Kirkpatrick" <>
Subject RE: Tomcat stability issues
Date Thu, 31 Aug 2000 15:58:42 GMT
I think a primary concern with respect to security is unknown.  I don't
think Tomcat has been tested thoroughly for things like buffer overflow
errors, and what their impact might be if exploited.  This is not to say
that Tomcat is less secure than Apache; instead, it is simply better known.

Apache, on the other hand, is very well known (there are holes, but they are
allegedly more known).  At the very least, many IS departments will feel
more comfortable with the security risks of running Apache for a web server,
routing JSP requests to Tomcat, as opposed to running Tomcat as a web

Does 3.2beta support things like cgi-bin?  This is one issue I don't think
works with 3.1.  There are other issues, such as support for mod_php and
mod_perl.  Not all content is JSP and HTML...

Scalability can be seen as an easy of use issue, too.  If you've already
separated your static and dynamic content logically (across Apache and
Tomcat), separating them physically should be a significantly easier


-----Original Message-----
From: Doug Ahmann []
Sent: Thursday, August 31, 2000 5:57 AM
Subject: RE: Tomcat stability issues

> -----Original Message-----
> From: Charles Sabourdin []
> I wonder if there is any "limte".
> something like for less then 2 000 hits a days you
> should use Tomcat and then use WebSever+Tomcat for
> more...
> Because this is a very big strat├ęgic issue, isn't it?

I'm not sure how it would matter. Whether you stick Apache in front of it or
not, Tomcat still has to handle each and every non-static transaction,

I have to admit I've never looked at the static file pipeline in Tomcat, but
I suspect it should be fairly well designed. Given that its written in Java,
and a little less mature, I'm sure it can't touch Apache's speed. But the
actual transferring of content bytes will probably be the bulk of the
transaction, and that will be native vm code anyway, so I wonder what the
differential for a static file transaction is?

Charles Forsythe brought up some scaling and security issues. Charles, I
think things like the Cisco Local Director can be configured to only allow a
single port to go through, so I don't see how it opens up any more security
holes to have Tomcat listening on 80 vs. Apache listening on 80. (I'm being
devils advocate, of course) A hacker could enter full servlet URIs to try to
run a particular servlet directly, but JServ won't prevent that sort of
thing, since it just passes everything through. JServ doesn't have any more
configuration options that Tomcat. So I'm still puzzled as to what the
advantage is for security, other than SSL.

As for scaling, Local Director (and other products like it I suspect) can be
configured to make a connection "sticky" to a particular machine, if your
app depends on it. IOW, if you are relying on the session, then you can
configure it so that all traffic from a particular user is routed back to
the machine the user was first connected to.

So if I'm understanding Charles correctly, you're saying that if your app is
heavy on static content, then it makes sense to have Apache at the front
end. At my previous company, we had a plan to have an independent image
server ( for instance). Wouldn't that handle what you're
talking about?

It seems to me that if the bulk of your site is jsp and servlets, there is
little to gain by having Apache on the front end.

IOW, I'm still not convinced. ;-) Does anybody else have any more insight?


> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!

View raw message