The Common Misconception
Almost everyone who is new to the Common Gateway Interface (CGI) makes the mistake of thinking of it as a programming language in its own right. CGI is not a programming language!
So what is CGI if it is not a programming language then?
The Common Gateway Interface is a way of connecting your web pages to other programs that are running on the server which visitors wouldn’t normally have access to. Most corporate web sites on the Internet today make use of CGI programs or scripts to allow their visitors to browse online catalogues or keep track of their orders in real time.
HTML pages are static in nature, if you request the same file, then you will get the same page (that is assuming that it has been updated between requests). A CGI generated page on the other hand can look very different each time you load it. This is because the CGI script or program that is used to generate it can dynamically build the page, including details such as the time of the request for example, to make the page different.
CGI Scripts, CGI Programs or CGI Applications?
The term you use will depend on the nature of the application that you are working on, although many people will tend to use and stick to a single term, there is a difference.
CGI Scripts – are interpreted by the server in real-time, and need to be interpreted each and every time they are run. For this reason they can be slower than a CGI program, but they are also easier to maintain as the code is accessible through a text editor.
CGI Programs – are compiled on the server they are running to help speed up the execution time and to hard code data paths for extra security. However, it can be difficult to compile programs on systems where access is limited, and the program will need to be recompiled for each platform you want to use it on.
CGI Applications – typically a CGI Application is a collection of CGI scripts or programs that work together to create a web-based interface for a program or database, although a single stand alone program or script can be described as an application if it does more than one type of server interaction.
Perl is not CGI
Perl scripts were often associated with CGI in the late 1990s because the language was well supported by the servers and was very good at text manipulation; which was ideal for building web pages on the fly. Most servers that recognise the .cgi file extension will open the file using the Perl interpreter. The connection between Perl and CGI is so strong that many believe that all CGI programs are written in Perl. This is simply not the case.
CGI applications can be written in a variety of different languages; the language of choice will often depend on what software is available on the server. Other languages that may be used in the development of CGI programs include Python, C++, Java and Visual Basic, to name but a few. So you don’t have to learn a new programming language to be able to create your own CGI scripts.
Advances in Web Interface Technology
Traditional CGI is a rather resource intensive way to interact with a server. The problem arises because of the way that CGI interactions were originally designed; in the case of CGI scripts that need to be interpreted at run time, the language interpreter was loaded each time it was needed. On a lightly used server, this notion of only using it when necessary could actually save server resources; however this method does not scale very well as each HTTP connection would create it’s own copy of the interpreter in memory where only the one was needed.
As more and more servers were making use of CGI technology, the problem of scalability soon became an issue. Because most of the earlier CGI scripts were written in Perl, Doug MacEachern created the
mod_perl Apache module to embed the Perl interpreter directly into the Apache server thus avoiding the need to start it for each Perl script requested.
Newer server technologies have tackled the problem of scalability by developing their own Application Programming Interfaces (APIs), which work in the same way as
mod_perl. These APIs load all the various language interpreters that are installed into the server’s memory when it is started, where they will remain in memory ready to use as soon as a request comes in.
Common CGI Equivalents
Microsoft’s server API is commonly referred to as the ISAPI filter; it runs in the background and redirects server calls (if they need to be parsed in any way) to run various Dynamic Link Libraries (DLLs) that do the work of parsing the language in use. Active Server Pages are parsed by the asp.dll, which contains information about the various ASP objects and methods that the server can understand. Extra programming interfaces can be added by registering new ASP components (COM objects) in the server’s memory space using the regsvr32 registration utility.
PHP: Hypertext Preprocessor (PHP) scripts are growing increasingly popular and so PHP is supported for a wide range of platforms and servers by offering different ways of using the interpreter. The PHP parsing engine is available as an ISAPI filter, Apache module or stand alone CGI program. As you can imagine, the PHP CGI executable loads a copy of the executable in memory for each call to a PHP page, and so is actively discouraged for performance reasons; recommended for use only on servers that use virtual hosts for security reasons.
The Future of CGI
The way we use our servers will continue to develop, and now that the performance issues surrounding CGI scripts have been highlighted, it seems the trend is to abandon the old style of CGI access in favour of the more robust server managed solutions. My own first CGI scripts were written in Perl, but I abandoned it in favour of ASP because Perl did not integrate so easily with my web pages.
It seems that the use of Perl for web sites is diminishing in favour of PHP, ASP or JSP; at least, it’s been quite a while since I saw the more popular sites I visit use Perl to interact directly with their visitors.
Adding Interactivity to Your Site
If you want to add interactivity to your own site, then I recommend that you use a technology that runs in the server’s memory space, particularly if you want a more scalable solution.
My original recommendation for a language to learn was, ironically, Perl. Now, I’d probably recommend something like PHP, despite not knowing how to write a full-blown script with it myself, it is widely supported and freely available. ASP is probably easier to learn if you are completely new to the programming scene, but ASP hosting is typically more expensive in comparison. Also, now that .NET has been officially released, a lot of the ASP sites are focusing on ASP.NET support and so the days of traditional ASP support are numbered.
The author, Rosemarie Wise, is a self proclaimed “web enthusiast” who set up her site, Web Site Ownerto share her experiences of being a site owner.