|
| 1 | ++++ |
| 2 | +author = "Emily Miller" |
| 3 | +title = "A brief dive into CGI" |
| 4 | +date = "2025-08-30" |
| 5 | +description = "Common Gateway Interface (CGI) is one of the oldest technologies still in use today to make web applications." |
| 6 | +tags = [ ] |
| 7 | ++++ |
| 8 | + |
| 9 | +[RFC 3875](https://www.rfc-editor.org/rfc/rfc3875) is the first RFC to discuss CGI in depth. Notably, this is not a formal specification, but rather a description of how CGI is commonly done in practice. To give a brief introduction to the technology from this RFC: |
| 10 | + |
| 11 | +> The Common Gateway Interface (CGI) [22] allows an HTTP [1], [4] |
| 12 | +> server and a CGI script to share responsibility for responding to |
| 13 | +> client requests. The client request comprises a Uniform Resource |
| 14 | +> Identifier (URI) [11], a request method and various ancillary |
| 15 | +> information about the request provided by the transport protocol. |
| 16 | +> |
| 17 | +> The CGI defines the abstract parameters, known as meta-variables, |
| 18 | +> which describe a client's request. Together with a concrete |
| 19 | +> programmer interface this specifies a platform-independent interface |
| 20 | +> between the script and the HTTP server. |
| 21 | +> |
| 22 | +> The server is responsible for managing connection, data transfer, |
| 23 | +> transport and network issues related to the client request, whereas |
| 24 | +> the CGI script handles the application issues, such as data access |
| 25 | +> and document processing. |
| 26 | +
|
| 27 | +Ok so, to briefly summarize what this is saying: |
| 28 | + - A CGI server handles parsing of HTTP requests and the networking side of things |
| 29 | + - It then uses a CGI script to handle the application side of the interface |
| 30 | + |
| 31 | +This fundamentally makes sense. This is a very similar to other technologies of the sort that you'll see, for instance PHP servers. |
| 32 | + |
| 33 | +In general, the way this looks in practice is something like the following: |
| 34 | + - Spin up a single "CGI Server" process, which listens for packets on a specific port |
| 35 | + - When it recieves a new TCP connection, spin up a new thread to handle the connection and continue listening |
| 36 | + - This new thread will then parse the HTTP request headers |
| 37 | + - It will then pick a script to run based on the URI (this is implementation defined) |
| 38 | + - It will then run a script in an implementation defined manner |
| 39 | + - And package its output into a new HTTP request |
| 40 | + |
| 41 | +## Picking a Script |
| 42 | + |
| 43 | +By default, this is usually done by indexing against a root directory. For instance, `/www/cgi-bin/`, may have all the CGI scripts for an application, and then the server will attempt to match the URI to a file within this directory. |
| 44 | + |
| 45 | +## Running the Script |
| 46 | + |
| 47 | +When running the script, by default it will store HTTP headers in environment variables such as `QUERY_STRING`, `CONTENT_LENGTH`, `REMOTE_ADDR`, etc. In the RFC description of the protocol, it actually abstracts this away using the term "Meta Variable", and states this is again implementation defined. |
| 48 | + |
| 49 | +It will then pass the request body in through `stdin` and output of `stdout` will be used to send the reply. |
0 commit comments