Comment by nostrademons | Hacker News Reader

Comment by nostrademons | Hacker News Reader

Parent Full thread

Man I feel old. :-/

Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim. There was no PHP, no Rails, no Django, and certainly no Node. If you wanted to do anything dynamic - like serving up content that you, the webmaster, did not write yourself - you had to write a custom webserver. Remember, this was back when C was the most popular programming language, Java was for hardware devices, Python was for academics, and Javascript didn't exist. Not many people wanted to write their own webserver.

CGI was a specification that would allow the webserver to launch an external program - written in any language you wanted - in response to an HTTP request, send it the request data, run arbitrary code, and write the response back to the web browser. The query params and other information about the request (path, user agent, host, request method, etc.) would be passed in environment variables. POST data would be passed on STDIN. The program would write the output HTML to STDOUT, and the webserver would echo that directly back to the browser.

It was slow, it was clumsy, it was insecure, and it was magical, because you simply couldn't do simple stuff like read from a database and dynamically generate a webpage otherwise, unless you wanted to write your own webserver.

The lines that the grandparent posted would fire up a Perl script and then import the CGI module to parse all the input data (no such thing as JSON back then; if you wanted the actual query params, you got "/reply" in your $ENV['PATH'], and "id=21654788&goto=item%3Fid%3D21648568%2321654788" in your $ENV['QUERY_STRING'], and had to parse them yourself). It also enabled some warnings and error checks for Perl to avoid some of the worst security nightmares. This was even more magical, because Perl offered string parsing & construction utilities and database libraries that were much easier than C, and so you could quickly write useful websites that did stuff instead of hand-typing HTML into your editor.

> before 1998 or so

Yeah, it's a bit older than that. According to Wikipedia, the CGI standard is from 1993 so it probably predates Apache itself by quite a bit (which was forked from the NCSA httpd which already had CGI support).

By 1998 mod_perl and mod_php had already taken over for most people and dynamic content was generated in-process. FastCGI existed but sadly didn't really take off, and the code languished until for some reasons a decade later it had a sudden and unexpected renaissance.

Man I feel old. :-/

Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim.

You should probably be feeling a bit older (and perhaps forgetful :).

PHP was around in the mid 90s, as were FastCGI, NSAPI and Javascript, Java's initial public target was web pages. Things like what eventually became AOLServer are also of that '95-ish vintage. CGI lived a long happy life in shared hosting, small project and development environments but in commercial use, it didn't last very long - it was just too slow.

> > Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim.

> You should probably be feeling a bit older (and perhaps forgetful :).

Perhaps we all should :).

> PHP was around in the mid 90s ...

True, and according to the PHP site[0]:

PHP as it's known today is actually the successor to a product named PHP/FI. Created in 1994 by Rasmus Lerdorf, the very first incarnation of PHP was a simple set of Common Gateway Interface (CGI) binaries written in the C programming language.

> ... Java's initial public target was web pages.

Not true, according to here[1]:

In 1991, a small group of Sun engineers called the "Green Team" believed that the next wave in computing was the union of digital consumer devices and computers. Led by James Gosling, the team worked around the clock and created the programming language that would revolutionize our world – Java. The Green Team demonstrated their new language with an interactive, handheld home-entertainment controller that was originally targeted at the digital cable television industry.

> CGI lived a long happy life in shared hosting, small project and development environments but in commercial use, it didn't last very long - it was just too slow.

Not quite true either. Unless one considers the following projects no longer in use:

- https://httpd.apache.org/docs/2.4/howto/cgi.html

- https://docs.microsoft.com/en-us/iis/configuration /system.webserver/cgi

- https://docs.python.org/3.4/howto/webservers.html

- http://www.yolinux.com/TUTORIALS/BashShellCgi.html

And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.

0 - https://www.php.net/manual/en/history.php.php

1 - https://www.oracle.com/technetwork/java/javase/overview/java...

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

Not true, according to here

I said public target. The thing was aimed at web pages, the sell was applets.

Not quite true either.

I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic. FCGI, NSAPI, in-process-tcl, plopping-piles-of-C-in-your-own-custom-apache-build were all solutions to that problem.

> > Not true, according to here

> I said public target.

You are technically correct, the best kind of correct.

> I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic.

And I agreed by stating:

> And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.

For efforts which do not need to scale, "classic CGI" can be a good fit. FastCGI can help increase the scale ceiling. Proprietary extensions can further do so.

Now the industry finds itself rediscovering CGI in the form of AWS Lambda[0] and Azure Functions[1], albeit addressing traffic concerns via "the cloud."

Funny how what was old is now new, eh?

0 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

1 - https://docs.microsoft.com/en-us/azure/azure-functions/funct...

You are technically correct, the best kind of correct.

Hah, no, I was the regular kind of correct, you just misread what i wrote - the best kind of read.

As to the other thing, I wasn't arguing about the merits of CGI just that the commenter's recollection was a few years off. A lot of stuff happened in that '94ish-'98ish period as the web went commercial.

Whether lambda is a forgotten CGI, it's a different tangent but I'm not sure I agree. The share-nothing architecture is still (give or take) the norm in HTTP request handling. CGI's attractive feature was implementation-language independence. Lamda's attractive feature is scaling independent of some big unwieldy discrete compute unit (hence 'server-less', you don't scale in servers).

I understood the first three lines :P

So... what would be an example of such an external program? Something that accesses a SQL database and changes values on the HTML page? I ask this specifically since you mention that database access would be prohibitively slow.

Or would you e.g. use CGI to call some script that changes the HTML? Let's say, post something that was written in an input box?

> 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.

Flashback to the days when URLs ended with “/cgi-bin”

Reply on news.ycombinator.com