Common Gateway Interface

from Wikipedia, the free encyclopedia

The Common Gateway Interface ( CGI ) is a standard for data exchange between a web server and third party software that processes requests. CGI is a long-standing variant of making websites dynamic or interactive, the first considerations of which go back to 1993.

functionality

A web server that supports CGI provides the external software with a runtime environment , which in particular consists of the following:

Environment variables
Environment variables (e.g. SERVER_NAME) that help the program to get information about the requests of the web server setting and situation. The designations and the format of the content are largely standardized.
Input and output channels
Provision of standard data streams . Usually the stdout channel is linked to the response from the web server, stdin to the request body that may be present.

advantages

Instead of only loading static pages from a web server, which are available there as a resource, it is also possible with CGI to generate HTML pages dynamically. These do not have to exist on the server at the time of the request, but can be generated by the CGI program.

In addition, CGI programs can be written in many programming languages, since the requirements do not go beyond the above.

disadvantage

This section needs to be revised: First it is stated that FastCGI could not prevail on a broad front (which I do not believe, since most of the literature I find recommends using FastCGI instead of web server modules), but then it is mentioned that that FastCGI is an alternative to web server modules and is even more efficient.
Please help to improve it , and then remove this flag.

A disadvantage of CGI execution is its relatively slow speed, as a new process is executed for each CGI call . This is why CGI is no longer used as often nowadays on highly frequented sites, because even approaches like FastCGI , which overcomes certain disadvantages of CGI, could at least not gain acceptance on a broad front.

To counter this problem, there are now z. E.g. for the Apache web server modules that integrate the interpreter for different script languages ​​(e.g. mod_perl for Perl , mod_python for Python etc.) directly into the web server process. This is only loaded once when the web server is started, instead of each time it is requested. Another, often even more efficient, option is to run the programs as external processes and transfer the browser's requests to them via FastCGI . In contrast to the integration as an Apache module, not only the interpreter of the programming language can be left running permanently, the application itself can also be loaded all the time and thus process incoming requests even more efficiently.

safety

The fact that programs that a third party has created can be executed on the web server is extremely relevant to security. It must therefore be ensured that a program started via CGI is only allowed to execute certain, restricted types of program routines (e.g. no deletion of files from the web server, etc.). With the Apache web server , the execution of CGI programs is secured against such cracker attacks with the help of the module mod_suexec , which are aimed at intrusion as the root user. The security measures are multi-level and so strict that many server administrators have switched to running other server-side languages ​​via CGI.

See also

Other server-side technologies

Web links

Web server interfaces
Logs

CGI  | SCGI  | FastCGI  | AJP

APIs

C NSAPI  | C ASAPI  | C ISAPI  | Java Servlet  | ASP.NET  | Python WSGI  | Ruby Rack  | JavaScript JSGI  | Perl PSGI  | Lua WSAPI 

Apache modules

mod_jk  | mod_lisp  | mod_parrot  | mod_perl  | mod_php  | mod_python  | mod_wsgi  | mod_ruby  | Phusion Passenger 

Web APIs

WSDL  | XML-RPC  | SOAP  | REST