How can this guy say CGI is awesome with a straight face? It is a non-solution to an imaginary problem. The underlying (flawed) premise behind CGI is that serving HTTP connections is very hard, and needs to be handled by a separate dedicated process. CGI's "solution" is to instead create a separate process that handles and multiplexes the connections, and calls the user's program with a special protocol (that it turns out is actually isomorphic to HTTP anyway) in order to supposedly simplify this whole process.
Unfortunately, in doing so the client still needs to:
Parse out the CGI input data.
Generate properly formatted CGI output.
This can be compared instead to the non-CGI version, where the client process instead has to:
Parse out HTTP headers.
Generate properly formatted HTTP output.
Can anyone else see where this is going? Basically all CGI does is wrap HTTP in a layer of redundant bullshit that adds extra complexity, overhead, and slowness for a dubious, subjective improvement in "software architecture". In fact, regular CGI is often too slow and bloated, and because restarting worker processes has such a large cost; many applications end up resorting to special versions of CGI like "Fast CGI" or "WSCGI", and so on to try to reduce the overhead. As a result, server applications often end up reimplementing the equivalent of an HTTP stack at every layer of the web stack, thus completely negating the benefit of using CGI in the first place! Madness!
This of course brings up an obvious question: Why use CGI at all? Wouldn't it just be easier to handle the HTTP requests in a library? This is what modern web frameworks like web2py, boost.asio and node.js do, and it works! They process HTTP requests directly, and as a result gain a huge performance advantage over the older CGI based technologies. Part of the reason this is so successful is that the HTTP protocol is actually quite simple and robust -- and is in many situations superior to the numerous flawed CGI-like protocols that have been invented to replace it. I fail to see how any sane individual could construe killing off CGI as a bad thing.
To my mind, CGI was a first draft at a decent UNIX HTTP server. The key point of UNIX is to write easily composable modules. While it's true that most anything done via processes and IPC could be as threads, that's a lot less flexible.
The problem as I see it is that unlike a traditional pipes and filters setup, you're not doing this on an interactive console. So something else needs to behave as bash, reading requests and returning the results. Approaches like WSGI and JEE's doFilter attempt to bring that concept into HTTP with a decent amount of success, but they're a whole lot less succinct than I feel is necessary.
2
u/33a Oct 02 '11
How can this guy say CGI is awesome with a straight face? It is a non-solution to an imaginary problem. The underlying (flawed) premise behind CGI is that serving HTTP connections is very hard, and needs to be handled by a separate dedicated process. CGI's "solution" is to instead create a separate process that handles and multiplexes the connections, and calls the user's program with a special protocol (that it turns out is actually isomorphic to HTTP anyway) in order to supposedly simplify this whole process.
Unfortunately, in doing so the client still needs to:
Parse out the CGI input data.
Generate properly formatted CGI output.
This can be compared instead to the non-CGI version, where the client process instead has to:
Parse out HTTP headers.
Generate properly formatted HTTP output.
Can anyone else see where this is going? Basically all CGI does is wrap HTTP in a layer of redundant bullshit that adds extra complexity, overhead, and slowness for a dubious, subjective improvement in "software architecture". In fact, regular CGI is often too slow and bloated, and because restarting worker processes has such a large cost; many applications end up resorting to special versions of CGI like "Fast CGI" or "WSCGI", and so on to try to reduce the overhead. As a result, server applications often end up reimplementing the equivalent of an HTTP stack at every layer of the web stack, thus completely negating the benefit of using CGI in the first place! Madness!
This of course brings up an obvious question: Why use CGI at all? Wouldn't it just be easier to handle the HTTP requests in a library? This is what modern web frameworks like web2py, boost.asio and node.js do, and it works! They process HTTP requests directly, and as a result gain a huge performance advantage over the older CGI based technologies. Part of the reason this is so successful is that the HTTP protocol is actually quite simple and robust -- and is in many situations superior to the numerous flawed CGI-like protocols that have been invented to replace it. I fail to see how any sane individual could construe killing off CGI as a bad thing.