Why should one use a http server in front of a framework web server?

Question

Web applications frameworks such as sinatra (ruby), play (scala), lift (scala) produces a web server listening to a specific port.

I know there are some reasons like security, clustering and, in some cases, performance, that may lead me to use an apache web server in front of my web application one.

Do you have any reasons for this from your experience?

Banns

What kinds of details do you want? – Winsor

Thank you @DaveNewton. I've changed the question. I just need reasons from someone who has already done it. – Banns

See also https://mcmap.net/q/449979/-why-use-nginx-with-catalyst-plack-starman/152948 – Hanghangar

Answer 1

• Part of any web application is fully standardized and commoditized functionality. The mature web servers like nginx or apache can do the following things. They can do the following things in a way that is very likely more correct, more efficient, more stable, more secure, more familiar to sysadmins, and more easy to configure than anything you could rewrite in your application server.
  • Serve static files such as HTML, images, CSS, javascript, fonts, etc
  • Handle virtual hosting (multiple domains on a single IP address)
  • URL rewriting
  • hostname rewriting/redirecting
  • TLS termination (thanks @emt14)
  • compression (thanks @JacobusR)
• A separate web server provides the ability to serve a "down for maintenance" page while your application server restarts or crashes
• Reverse proxies can provide load balancing and fault tolerance for you application framework
• Web servers have built-in and tested mechanisms for binding to privileged ports (below 1024) as root and then executing as a non-privileged user. Most web application frameworks do not do this by default.
• Mature web servers are battle hardened and stable. By stable, I mean that they quite literally almost never crash. Your web application is almost certainly far less stable. This gives you the ability to at least serve a pretty error page to the user saying your application is down instead of the web browser just displaying a generic "could not connect" error.
  • Anecdotal case in point: nginx handles attack that would otherwise DoS node.js: http://blog.nodejs.org/2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/

And just in case you want the semi-official answer from Isaac Schluetter at the Airbnb tech talk on January 30, 2013 around 40 minutes in he addresses the question of whether node is stable & secure enough to serve connections directly to the Internet. His answer is essentially "yes" it is fine. So you can do it and you will probably be fine from a stability and security standpoint (assuming you are using cluster to handle unexpected termination of an app server process), but as detailed above the reality of current operations is that still almost everybody runs node behind a separate web server or reverse proxy/cache.

Lemkul

Servers like nginx are also very competent at handling very high concurrent load, which is done using a handler model that allows very many concurrent requests per thread. This is part of the reason for the far-superior throughput for serving static content. This lets your app server just concentrate on its job. – Celesta

Indeed. This is what I mean by "more efficient", but generally they are going to be better-suited than your app framework from many perspectives: concurrency, latency, resource utilization. Sometimes your web framework may offer comparable performance against one or more of these metrics, but when the big picture is considered, there's still good reason to put your application framework behind a dedicated web server. – Lemkul

Answer 2

Quite often the frameworks do everything you need, but sometimes, adding a layer on top of that can give you seemingly free functionality like compression, security, session management, load balancing, etc. Still, adding a web server may also introduce security issues, for example, chances are your web server security may be compromised easier than Lift by itself. Also, some of the web frameworks are extremely scalable and may even be hampered by an ill chosen web server.

In summary, if you require web server like functionality that is not provided by the framework, then a web server may be a very good option, but keep in mind that it's one more thing to configure properly and update regularly with security patches, etc.

If for example, you just need encryption, or compression, then you may find that adding the correct library or plug-in to your framework may do just that (and only that)

Mensch

Answer 3

I would add:

• ssl handling
• for some servers like apache lots of modules (i.e. ntml/kerberos authentication)
• Web servers are much better for some things compared to your application, like serving static.

Mas

Answer 4

With a proxy http server, the framework doesn't need to keep an http connection open for giving the computed content and can then start serving some other request. It acts as a buffer.

Malchy

Answer 5

It's an issue of reinventing the wheel. Most frameworks will give you a development environment but for production it's usually good practice to use a commercial/open source project that is able to deal with all issues that arise during production.

Guys building a Framework will have the framework to concentrate on whilst guys building a server are doing just the same(perfecting).

Miliary