4 ms·

What is CGI?

AdieuToLogic 7y ago
> What is CGI? Common Gateway Interface. It's a specification for how web servers can process HTTP(S) requests dynamically. EDIT: If you are wondering what modern equivalents are, AWS Lambda[1] and Azure Functions[2] are Liskov substitutable[3] as they pertain to CGI programs. Both of these products provide benefits beyond what a "classic CGI system" could offer, of course. 0 - https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface 1 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html https://docs.aws.amazon.com/lambda/latest/dg/welcome.html 2 - https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview https://docs.microsoft.com/en-us/azure/azure-functions/funct... 3 - https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle
nostrademons 7y ago
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.
- pvg 7y ago
  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.
  - AdieuToLogic 7y ago
    > > 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://httpd.apache.org/docs/2.4/howto/cgi.html - https://docs.microsoft.com/en-us/iis/configuration https://docs.microsoft.com/en-us/iis/configuration /system.webserver/cgi - https://docs.python.org/3.4/howto/webservers.html https://docs.python.org/3.4/howto/webservers.html - http://www.yolinux.com/TUTORIALS/BashShellCgi.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 https://www.php.net/manual/en/history.php.php 1 - https://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html https://www.oracle.com/technetwork/java/javase/overview/java... 2 - https://en.wikipedia.org/wiki/FastCGI https://en.wikipedia.org/wiki/FastCGI

What is CGI?

> What is CGI? Common Gateway Interface. It's a specification for how web servers can process HTTP(S) requests dynamically. EDIT: If you are wondering what modern equivalents are, AWS Lambda[1] and Azure Functions[2] are Liskov substitutable[3] as they pertain to CGI programs. Both of these products provide benefits beyond what a "classic CGI system" could offer, of course. 0 - https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface 1 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html https://docs.aws.amazon.com/lambda/latest/dg/welcome.html 2 - https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview https://docs.microsoft.com/en-us/azure/azure-functions/funct... 3 - https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle

nostrademons 7y ago

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.

pvg 7y ago
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.
- AdieuToLogic 7y ago
  > > 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://httpd.apache.org/docs/2.4/howto/cgi.html - https://docs.microsoft.com/en-us/iis/configuration https://docs.microsoft.com/en-us/iis/configuration /system.webserver/cgi - https://docs.python.org/3.4/howto/webservers.html https://docs.python.org/3.4/howto/webservers.html - http://www.yolinux.com/TUTORIALS/BashShellCgi.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 https://www.php.net/manual/en/history.php.php 1 - https://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html https://www.oracle.com/technetwork/java/javase/overview/java... 2 - https://en.wikipedia.org/wiki/FastCGI https://en.wikipedia.org/wiki/FastCGI