tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Miller" <>
Subject RE: Optimal Settings to use Tomcat as a HTTP File Server
Date Mon, 13 Jun 2011 19:58:23 GMT
>> Enlighten me: what is "the" reason that this is common practice?

The most obvious reason for having HTTP server in front of an Application Server (Tomcat)
is that there are many things that you can do at/in the HTTP server that you don't have available
to you inside Tomcat. Things like:
-Load balancing
-Static image serving (much more economical because the HTTP server is much lighter "weight"
than a JVM/App server)

The most common/safest configuration is the HTTP server being directly available to the internet
and the Application Servers being hidden behind firewalls with only 1 port per IP address
forwarded through the firewall. 

The most common reason for this is that an Application Server requires usually requires access
to many more things than a simple HTTP server (Databases, Network Disk space, etc..) and those
other things are MUCH more difficult to secure against external intrusions. Also if you want
to do clustering with failover or sequential updates it is better to have something in front
of the actual application server that doesn't need to be changed much. It will just simplify
ongoing daily maintenance (it looks more complicated but in the long run it makes things a
lot simpler). HTTP servers are also much more efficient at processing HTTP connections and
HTTPS traffic than Application Servers.

Besides, if you want an outage message, where would you serve that from if not from an HTTP


-----Original Message-----
From: Christopher Schultz [] 
Sent: June 13, 2011 3:44 PM
To: Tomcat Users List
Subject: Re: Optimal Settings to use Tomcat as a HTTP File Server

Hash: SHA1


On 6/11/2011 4:00 AM, Sriram Narayanan wrote:
> On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz
> <> wrote:
> Sriram,
> On 6/10/2011 1:49 PM, Sriram Narayanan wrote:
>>>> Having one application serve static content, and having other
>>>> applications serve other content (accept http requests, perform some
>>>> processing, and send back responses, for e.g.), is actually a widely
>>>> accepted and tested mechanism of using various stacks for various
>>>> tasks.
>> Sure, but it's not always necessary. More moving parts when they aren't
>> necessary just results in tougher management and greater opportunity for
>> security mistakes.
> For those that need it, this is what is done. Phrases such as "moving
> parts", etc give the impression that it's all going to be very
> complicated when it's not.

My point is that most don't need it. It's evidently become so "standard"
that people do it because "it's what everybody does", instead of for
some specific reason.

For instance, we use Apache httpd in front of Apache Tomcat because we
need a single web server process to proxy to multiple back-end Apache
Tomcat instances. We also have multiple back-end servers and use httpd
as a load-balancer. If we had an F5 out front, we would probably remove
Apache httpd from the mix.

Configuring two web servers is (debatably) double the complexity. I
didn't say it was "very complicated"... I just said it was "more

>>>> In fact, the vast majority of websites out there specifically stick in
>>>> proxies and such in front of tomcat for  SSL termination, load
>>>> balancing, and static content serving.
>> I'm not sure I would say "the vast majority", but certainly many are.
>> There's no need to give the impression that some other web server in
>> front of Tomcat is a best practice: it's merely a common practice.
> This is not giving an impression. There's a reason that this is common practice.

Enlighten me: what is "the" reason that this is common practice?

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message