>> 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: -Caching -Proxy -Load balancing -Static image serving (much more economical because the HTTP server is much lighter "weight" than a JVM/App server) -etc... 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 server? Bill -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: June 13, 2011 3:44 PM To: Tomcat Users List Subject: Re: Optimal Settings to use Tomcat as a HTTP File Server -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sriram, On 6/11/2011 4:00 AM, Sriram Narayanan wrote: > On Sat, Jun 11, 2011 at 1:14 AM, Christopher Schultz > <ch...@christopherschultz.net> 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 complicated". >>>> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk32aIoACgkQ9CaO5/Lv0PCRcwCcD3dtgWWo5LjQoYCdYGxD6eut qjAAn2DH2dXpwCGXuiM84qc4YbofgWHn =w0j7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
