I feel like CGI Perl scripts back in the late 90s was definitely a critical reason for me picking up on programming, web dev (as a high school kid), and eventually becoming a professional web developer, and software engineer.<p>The whole web dev paradigm back then starting from basic HTML files, to client JS, to server-side Perl CGI scripts, was just really easy to wrap my head around, and actually create usable products out of. It maps well to a Windows OS file system -- you have these HTML files sitting in folders, you can write them locally and open them locally to see them. Upload to a server via FTP in the exact same structure, and see it work on the internet. If some files are CGI scripts, they run some code on server before output. Input from browser comes in as stdin in the script, and output to browser is just stdout. It was simple enough that as a high school kid, I was able to start one of those "webmaster services" (providing guestbooks, counters, etc.). I have nothing but fond memories building scrappy stuff back in those days.
In the early 2000s, Sun's patching support website, sunsolve, was a massive Apache/CGI empire. Perf. problems were rife and by early 2002 the whole thing was grinding to a halt under traffic.<p>It just happened to be intern season. In walks some fresh-faced kid and installs mod_perl. Like magic, the entire website stands up, dusts itself off and starts working again. CPU load drops by two thirds. I think the senior engineers were kind of pissed but couldn't really say anything. I think the kid got a beer or two out of the whole thing. (And of course got an offer to stay.)
My first code for CGI was all done in C. When I found Perl, there was no looking back, never used C for CGI again.<p>While I haven't written any significant Perl in a long time, I will always appreciate how much it improved things for me back then.
CGI was a wonderful paradigm for when I was first learning web development, a few years after this. A shell account somewhere, some scripts that just had to deal with stdin and stdout, and you could create amazing web experiences. Previously I only knew BASIC, but CGI let me start to share my weird little creations with the world.<p>There should be more simple ways for young people to write and share programs with each other. Maybe that’s what Roblox is, to an extent? I haven’t used it myself.
Am I the only one here who remembers <i>Philip and Alex's Guide to Web Publishing</i>? <a href="https://philip.greenspun.com/panda/" rel="nofollow">https://philip.greenspun.com/panda/</a><p>OK, looks like my memory isn't that good. panda came out in 1998. At the time I was working for a company that paid Y2K bonuses to dissuade us from quitting and moving to the Bay Area. I often wonder how different my life would be if I had done that.<p>Who am I kidding? I was having way too much fun writing motion control software to do any of that Web crap ;-)
I used Lincoln Stein's CGI.pm module (<a href="https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#CGI.pm-HAS-BEEN-REMOVED-FROM-THE-PERL-CORE" rel="nofollow">https://metacpan.org/pod/distribution/CGI/lib/CGI.pod#CGI.pm...</a>) all the time back then. I wrote a Perl module for SMIL which I called SMIL.pm and emailed him to tell him and was thrilled when he responded. I'm strangely saddened to hear it has been removed from Perl.
CGI is in my list of what I consider "core Web technologies", and still include and use in my projects.<p>I haven't written it up yet, but basically it's things which are supported by almost every browser and/or almost every web server.<p>Other things on the list are parts of HTML 3.2, like <p> tags, the standard format of access.log, HTTP/1.1, etc.<p>I try to not use anything outside of that list in my projects, some JS things being an exception (which I feature-check before using)
When I got to college and got online in 1995, I pretty quickly learned about CGI scripts and the cgi-bin directory, which of course my school did not have enabled on campus-wide accounts (security risks). I really wanted cool stuff like a web hit counter on my page. A lot of web hosts at the time would advertise something like "5MB of space and your own cgi-bin!" and I eventually got to one of these, got into Perl, and start making stuff using Berkeley DB and other on-disk databases. Eventually I outgrew this, found PHP & MySQL, found a web host who supported it, went to work at that web host, ... All said, CGI's were totally the reason I got into internet programming.
FCGI is still quite useful. You can use FCGI, Apache, and Go to get quite good performance. FGCI will spin up more Go servers as needed, and the Go servers can process multiple transactions without reloading the program. Probably outperforms node.js.<p>Basic CGI reloads the worker program for each request, which is secure but slow. FCGI is an orchestration system. Like Kubernetes, but with lower labor costs. If one of the workers crashes, a new one will be started.<p>You can run stuff like this on US$10/month shared hosting accounts. To scale up, put a load balancer in front and a replicated database on the back.
While CGI scripts written in perl and shell script were all the rage, I remember using C (and ODBC) quite fondly and successfully. It wasn't until I encountered the webscr.cgi at PayPal that was more than a GB compiled and spanned millions of lines of C language that I realized the error of my ways.
CGI still work great if you know your constraints and for whom you're building stuff. It is underrated alongside its cousins FCGI and SCGI. A ton of little tools work great as CGIs.
It wasn't <i>easy</i>, but everything was so much simpler back then.<p>Modern Web Development are needlessly complicated. Both Front End and Back End. Oh... and deployment.
I had no idea what I was doing back then - copying scripts from MSA, no idea what chmod or ftp binary mode or even what the unix system I was telnetted into was (couple of years before). Managed to get things working though.<p>No mention of server-side includes, which were great -- you could include a nav bar on all your pages and just have one file to update, you could include a 'last updated' line at the bottom based on the file modification, you could include a visitor counter.<p>I did a website for a local art+book shop back in 1997, it was awful. Stopped updating it after 6 months, but it was kept online for some reason - even after the shop closed. archive.org shows the SSI counter was still incrementing in 2005. I assume the (copy-and-paste) code ran a script that opened a file, incremented the number, wrote it back to the file, then printed the number.
The non-static portions of the Tarsnap website still consists of CGI scripts written in C.<p>Sure, forking a process per request isn't fast... but I'd love to have enough traffic for that to matter.
I still have cgi scripts running, I assume, somewhere.<p>Sometimes you just need a single file that does a few things and mostly behaves like a webpage. It doesn't need to be deployed or managed or anything. I had this one that served approximately seven requests on average for over a decade. It's simple. It doesn't need any love. It's in the documentation for the overall site because I wrote the documentation, but it isn't "omg this needs an APP and a BACK END and we have to worry about SCALING."<p>I still have a book somewhere on CGI with Perl and C, from the 1990s. Probably due for a purge.
One of the best aspects of CGI is how easily tested a CGI program is. All you have to do is set a couple environment variables and connect your request entity to stdin, expecting things on stdout. What could be better?
Perl had an interesting invention - taint mode (although much later). All inputs from the network were marked as tainted and you got an error if you tried to use I/O with them. You had to untaint the data by passing to if/case statement or at least a regex.<p>IMO when programmer did not fight it, it was very good for sanitizing the input. Curious why this did not get more widely adopted?
I have recently been using something very similar to CGI scripts on my Jetforce Gemini server. It actually goes in cgi-bin although its not exactly CGI. I used it to make an interface to Zork.<p>You can try it out if you have a Gemini client: gemini://zork.club<p>For these types of things I recommend the diohsc client <a href="https://repo.or.cz/diohsc.git" rel="nofollow">https://repo.or.cz/diohsc.git</a> although you may need to build from source since he had an issue with Jetforce compatibility and not sure if it's fixed in cabal yet.<p>But any Gemini client will work such as av98 or Lagrange.<p>The guy who made diohsc set up something a little more sophisticated using SCGI and he has several interactive fiction on his Gemini server (if it's up). (You can search on gus.guru for gemrepl).
I recall writing CGI scripts in perl. I met some guys are work that used C and I was shocked. But not as shocked as my boss. It took them so long to deliver applications compared to cranking out perl.
Random question but I've often heard people refer to computer graphics in movies and television as "CGI" instead of "CG." I've always wondered: is this just a weird conflation of terminology from an era when Common Gateway Interface was a thing, around the same time fancy computer graphics technology was starting to take off in the 90s? Or is there there an alternative, legitimate reason why one would refer to <i>C</i>omputer <i>G</i>raph*I"cs as "CGI?"
Ah, those were the days... few people really cared about web security back then and Perl allowed you to get really creative :). <a href="https://seclists.org/bugtraq/1997/Jun/67" rel="nofollow">https://seclists.org/bugtraq/1997/Jun/67</a> or my favorite <a href="https://insecure.org/sploits/glimps.http.badchars.html" rel="nofollow">https://insecure.org/sploits/glimps.http.badchars.html</a> .
I started learning HTML back in early high school (~96). Very fond memories of doing our warm-up laps in gym class with a friend (who is my part-time LLC business partner to this day), and we tried to remember whether it was the 'a' or 'href' part that came first. We heard rumors that there were web developers who would make $100/hr programming. The combination of those dollar signs and the magic of being able to write something that would manipulate the screen (the latter being much more motivating, to be honest) is what kept me up until 3 or 4am many nights/mornings, only to wake up at 6am to hang out with my dad before he left for work. This resulted at least one time in in me falling asleep in my high school health class, waking up entirely alone after the period ended. Oops.<p>I felt so many times that I was _so close_ to being able to understand how to do this new, exciting CGI thing. Something about the form action? What should that be -- the filename I want to write? Do I put the counter + 1 value there? Oh, it's just GET or POST. Oops.<p>I bought a book, CGI How-TO, one day at Media Play[0] with some friends while on a brief break from our LAN party setup. (Coaxial networking was a huge PITA - as soon as someone came or left, our in-progress game was terminated.) It discussed C and Perl. That book sits on the bookshelf four feet away from me right now for the nostalgia and the love of learning. A few years later, I asked my parents for Learning Python Programming for a Christmas gift. I flipped through it trying to grok what a tuple was. That thick book sat on my shelf for a lot longer than it should have, but the joy of having such a tome of possibilities was unlike most others.<p>[0] <a href="https://en.wikipedia.org/wiki/Media_Play" rel="nofollow">https://en.wikipedia.org/wiki/Media_Play</a>
The linksys WiFi router I was using until last year used cgi app for the admin interface.<p>My first web application was developed in 1999 in IISAPI (VC++) running obviously on IIS. I had to write a rudimentary session storage (in plain txt file!), because it was not provided by the framework.
Made a lot of use of this site:
<a href="https://www.scriptarchive.com/" rel="nofollow">https://www.scriptarchive.com/</a>
I do have fond memories of the simplicity of CGI, but also remember the big speedup and scalability improvement when we swapped over to NSAPI (no more forking, pooled processes, etc).<p>Kind of interesting that "serverless" (AWS Lambda, etc) seems to be going through the same evolution now. That is, initially liking the simplicity then hitting a wall with performance and making it more complicated.
> In many ways then, it was CGI — not JavaScript — that was the start of web applications.<p>"Before we had these nifty LED bulbs, we burned candles."
I remember when Tripod offered free Perl scripting, I played around with CGI.pm and made what might have been the most terrible forum script ever made - luckily no one else ever used it.<p>Also I think I tried to get the forum from Matt's Script Archive (which is still around by the way) working but couldn't.
Good read, thanks for sharing. It’s quite remarkable how we still use the same concepts today almost 30 years after it was invented. Modern web apps are ‘just’ text boxes over databases with logic in between to serialise it over the network in a request / response driven manner (using string-based key/value pairs). Today there’s a stack of JavaScript on top of it but it basically still boils down to the same principles.
I remember SSI. I haven't seen much of that albatross in ages.<p>Good riddance.<p>I did write an entire CMS in PERL, once.<p>I still wake up screaming...
Actually writing CGI scripts was a bit before my time, but I have very fond memories of installing and using Newspro and Imagefolio on my old web pages.