Topic: CGI | ||||||||||||||||||||||||||||||||||||
CGI (Common Gateway Interface) was one of the first ways to write programming content for Websites. As such, it enjoys
nearly universal support, so I use it pretty extensively.
Advantages over (for instance) Tcl or ASP programming:
Every server supports CGI programming. A great deal of ready-to-use CGI code can be found for free on the internet. Most ISPs also allow CGI programming (although some will restrict you to scripts that they have approved, for security and system stability reasons.) The CGI protocol is extremely general, so that programs may be written in nearly any language. Perl is by far the most popular, with the result that many people think that CGI means Perl. But C or Python are fine or heck, I suppose you could write CGI in Forth or something.
Unlike embedded scripting languages (ASP scripts under IIS or Tcl under AOLserver) each call to a CGI program requires a process to be started, run, and stopped. On heavy sites this can add up to a lot of load for the machine. Worse, the process boundary means that database connections must also be established for each hit, and that can add up to far more load as compared to any platform which establishes database connections in advance and doles them out to embedded scripts. Since a CGI is an arbitrary program running with the userid of the Web server, a malicious or simply incompetent CGI programmer can wreak serious havoc on the system. With careful security planning, most of this risk can be avoided, but it does mean that you pay ISPs extra (usually) for the ability to run arbitrary scripts. Fortunately, a crash in a CGI program doesn't crash the server (unlike Apache modules), so at least you have a little win.
This marks the rest of the output as HTML, and you can usually get away with no more headers than those.
Input to your script comes in two ways. Anything that's part of the request (i.e. a POST content) is on the standard input. And then there are lots of other things (including the URL and query part of the URL) which are in environment variables. (As you can see from the use of standard input and output and environment variables, the CGI interface was designed in a C-influenced Unix environment.) The environment variables actually defined vary from server to server somewhat, but these are pretty standard:
|