CGI.pm

CGI.pm is a ready-made toolkit for programmers, a so-called module. It belonged to the Perl programming language, which used to be very commonly used for web pages. The job of CGI.pm was easy to describe: a visitor fills out a form on a web page and clicks submit. This input arrives at the server, i.e. the computer that delivers the web page, as a rather confusing data stream. CGI.pm took in this data stream, sorted it, and made the input available to the program cleanly as individual values. Conversely, it helped build a finished HTML page from the result, meaning the text form in which web pages arrive at the browser.

The building block behind the early participatory web

In the early years of the web, pages were pure documents. They looked the same to every visitor and only changed when someone edited the file by hand. Guestbooks, search forms, order forms, and forums, however, needed pages that were recalculated for every request. This is exactly what CGI, the Common Gateway Interface, was for. It is an agreement on how a web server starts a program and hands it the visitor’s request.

This agreement, however, was very rough. Every programmer had to decode the input themselves, and mistakes happened constantly in the process. CGI.pm did this work once and for all, and correctly. From 1997 onward, the module was even shipped directly with Perl. Anyone who wanted to build a dynamic page needed to install nothing, just write a single line of code.

Historically, this is significant because a large part of the early commercial web came into being this way. Shops, newsletter sign-ups, and search engines ran on Perl scripts with CGI.pm. The module lowered the barrier to entry so far that even hobbyists could take part. Without this low threshold, the web would have grown considerably more slowly.

From form to finished page

The process was always the same. The visitor submits a form, and the web server then starts a Perl program. CGI.pm reads out the data sent along and puts it into a kind of lookup table. The program then simply asks for the value of a particular field, for example the email address entered. The programmer did not need to worry about whether the data was transmitted in the address bar or in the background.

For the return path, the module offered functions that generate HTML text. One call supplied the necessary preamble for the browser, further calls generated headings, paragraphs, or input fields. So one could write a complete page without typing a single angle bracket oneself. It was exactly this part that later drew criticism, because it made design and program logic indistinguishably intertwined.

A common misconception is that CGI.pm is a programming language or a server. Neither is true. It is merely a helper library that takes over tedious routine work. And it is also not the same as CGI itself: CGI is the interface, CGI.pm was a convenient way of using it in Perl.

What remains of it today

In modern web development, one hardly encounters CGI.pm anymore. Since 2015 it has no longer been shipped automatically with Perl, and it is officially considered deprecated. Newer Perl projects instead use frameworks such as Mojolicious or Dancer. Outside of Perl, other tools have taken over the field anyway, such as PHP, Python with Django, or JavaScript in the Node environment.

Nevertheless, a surprising amount of old stuff keeps running. In companies, at universities, and in public administration there are systems that were built twenty years ago and still fulfill their purpose. Such software is called legacy systems. Anyone who maintains them quickly comes across CGI.pm in the source code.

For everyone else, the term is mainly a piece of technology history. It comes up when reporting on the beginnings of the web, or in discussions about technical legacy burdens. Anyone who understands what CGI.pm did also understands what today’s web frameworks fundamentally do: receive requests, process them, and send back a response page. The idea has remained, only the tools have become more convenient.