> I understood the first three lines :P

> So... what would be an example of such an external program?

The external program is responsible for producing the entirety of an HTTP response; headers and the message body (see here[0] for details). CGI allows a web server to provide what it knows from an HTTP request to an arbitrary program and expects it to write the response as it sees fit.

Think of it as a specialized case of "fork-exec"[1] where the "child process" has the responsibility of writing the raw HTTP content to the "parent process" (the web server).

In the CGI model, each request causes a "fork-exec"[1] and, as such, any interaction with other services (such as a database) requires connecting, using it, then disconnecting each time. This can quickly swamp server resources, which lead to the definition of FastCGI[2] to help alleviate this type of thrashing.

HTH

0 - https://tools.ietf.org/html/rfc2616#section-4

1 - https://en.wikipedia.org/wiki/Fork%E2%80%93exec

2 - https://en.wikipedia.org/wiki/FastCGI

I like reading old Perl code. It's much more interesting than the Javascript code that displays stupid YouTwitFace plugins.

BTW, is this kind of specialised fork-exec code that writes back HTML code to the parent process still in use?

> BTW, is this kind of specialised fork-exec code that writes back HTML code to the parent process still in use?

Yes, but is most likely found in intranet situations. As others have noted, commercial offerings typically use an application server style approach, as that greatly contributes to being able to scale.

However, not everything has to scale ;-).

This is the same way that PHP works if you don't use the fast CGI modules. The webserver runs the php executable just as apache would've run perl in the gp's example.