The HTTP protocol is defined to be stateless. For a protocol that allows an essentially non-linear look into a linear, static, “book-like”, hierarchical structure called web page, that makes sense. All the serving application needs to know can be encoded in a single request, which was also done to prevent DoS attacks since the server does not keep any data for any client what-so-ever, thus preventing running out of memory when hit with too many requests.
As soon as web pages started to be non-static and allowed clients to manipulate server-side data, problems abounded. Now there is the need to save state. Think of a typical website that allows you to log in. That login state needs to be saved between requests to be remembered the next time your browser requests a page. Read the rest of this entry »
Do we still need a complete webserver the likes of apache, for todays server-side dynamic frameworks? No – we don’t.
If you ask why, think about what a webserver is for (a good look at the HTTP spec and apache docu will do). It is responsible for content-types, authentication or help with caching and can also do name-mangling, load-balancing and more with the help of plugins. Now, which of these can a dynamic-language framework also do or even do better? Yep, that’s right, all of them.
The scripting language of choice decides everything for its own dynamic content: The content-type, caching-directives, how to handle each path and even which VM is least loaded for balancing. Authentication is in almost all cases not done through the primitive http-auth anymore, but with the help of the DB and sessions.
If a request for CGI content comes in, the webserver just passes it to the scripting language which takes care of everything itself and passes the result back to the webserver for sending to the client.
Let me emphasize that: The webserver is one more step in the loop, which we don’t need anymore for dynamic content.
Static content, like images, should be served from a different (sub-) domain anyway for easier CDN distribution, and for that webservers are still the handler of choice.
That’s why frameworks like RoR come with their own lightweight webserver.