Applications for the Web
There obviously needs to be some kind of protocol for the web server and the web
application to pass the HTTP request and the returned HTML page between them.
The earliest mechanism for this was called the Common Gateway Interface (CGI).
The web server would decompose the request into environment variables, which it
would add to the environment of the handler program when it was invoked, and
pass the body of the request, if there was one, to the program via its standard input.
The program would then simply pipe the HTTP response it generated to its standard
output, which the web server would catch and return to the client.
Due to performance issues however, CGI is slowly falling out of favor these days,
and writing a Python CGI application is something that should be avoided if at
all possible.
Recycling for a better world
CGI works, but the major drawback is that a new process has to be launched for each
request. Launching processes is expensive in terms of operating system resources,
and so this approach is very inefficient. Alternatives have been developed.
Two approaches became common. The first was to make web servers launch and
maintain multiple processes at startup, ready to accept new connections— a technique
known as pre-forking. With this technique, there is still a one-process-per- client
relationship, but the processes are already created when a new client connects,
improving response time. Also the processes can be reused instead of being
re-created anew with each connection.
Alongside this, web servers were made extensible and bindings were created to
different languages so that the web application could be embedded within the web
server processes themselves. The most commonly seen examples of these are the
various language modules for the Apache web server for languages such as PHP
and Perl.