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

Answer 1

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)

Answer 2

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).

Answer 3

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.

Answer 4

• 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.

Answer 5

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.