Question

This question asks about the disadvantages of ‘cgi-bin based’ services. As far as I can ascertain, apart from perhaps the naming convention, nothing much has changed over the years as far as web based client/server interaction is concerned. There is of course now the option to use AJAX clients but ultimately they are still stateless and code on the server, whatever language it is written in, still waits for input to be sent via ‘GET’ or ‘POST’ methods.

Having been out of the loop as far as web programming is concerned for quite a while, am I missing something obvious?

To clarify my question: The question I referred to suggests that ‘cgi-bin’ based systems are no longer in use, what is the new alternative?

@sarnold. Thank you for your answer. Just so I am 100% certain about this, even if a system is developed using the ‘latest and greatest’ server platform (I guess this would be a .net based system or Linux equivalent) it is still, ultimately, just a program, or programs, running (if using fast cgi) or waiting to be started on a server, so there really hasn’t been any change over the years. If that is the case what alternative is Brian referring to in his question?

Answer 1

The largest changes have been in tools like mod_php that execute the code directly in the address space of the web server and FastCGI which implement something very nearly identical to the CGI protocol, but with a handful of long-lived processes, rather than fork(2) + execve(2) of a new interpreter for every single request.

Of course, both approaches have problems: executing the interpreter directly in the address space of the web server is potentially horrible for reliability and security: the server (typically) runs with the same privileges all the time, so separating users is (typically) impossible. Further, flaws in the interpreter can be quite common, so it isn’t a good solution for shared hosting environments, because any user could run arbitrary code with the privileges required to access all the data of all the other users on the system.

The FastCGI approach almost keeps the same speed; it does sacrifice some speed for copying data around between processes, but this isn’t a real big deal for anyone except huge volume sites. But, you can run multiple FastCGI systems as different user accounts attached to different locations of the single ‘web server’ (e.g., http://example.com/public/ runs under account www-public and http://example.com/private/ runs under account www-private), and the FastCGI systems don’t need to run with the same privileges as the web server.

Of course, there are also servlet systems where the server calls into compiled callbacks (frequently, compiled to bytecode) code that is linked into the server process. Much less “scripting”-feel.