RFC 3875

The Common Gateway Interface (CGI) Version 1.1

📅 published October 2004, from ietf

Status of this Memo 🌸

Okay bestie, let's start with the paperwork 📄💖 This is RFC 3875, called The Common Gateway Interface (CGI) Version 1.1. It was written by D. Robinson and K. Coar from The Apache Software Foundation, and it came out in October 2004. It's Informational, and the title block doesn't list any RFCs it obsoletes or updates. It's from the Network Working Group, if you're into that 🎀

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. So it's an info doc, not a standard, and you're free to share it 💅

Copyright (C) The Internet Society (2004).

IESG Note ⚠️

This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. 🙈

Abstract 🦋

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Right now, the supported information servers are HTTP servers ✨

The interface has been used by the World-Wide Web (WWW) since 1993 🌍 This specification defines the 'current practice' parameters of the 'CGI/1.1' interface, which was developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines how to use the CGI/1.1 interface on UNIX(R) and other, similar systems 💜

Table of Contents 📚

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   4
    1.1. Purpose  . . . . . . . . . . . . . . . . . . . . . . . .   4
    1.2. Requirements . . . . . . . . . . . . . . . . . . . . . .   4
    1.3. Specifications . . . . . . . . . . . . . . . . . . . . .   4
    1.4. Terminology  . . . . . . . . . . . . . . . . . . . . . .   5

2.  Notational Conventions and Generic Grammar. . . . . . . . . .   5
    2.1. Augmented BNF  . . . . . . . . . . . . . . . . . . . . .   5
    2.2. Basic Rules  . . . . . . . . . . . . . . . . . . . . . .   6
    2.3. URL Encoding . . . . . . . . . . . . . . . . . . . . . .   7

3.  Invoking the Script . . . . . . . . . . . . . . . . . . . . .   8
    3.1. Server Responsibilities  . . . . . . . . . . . . . . . .   8
    3.2. Script Selection . . . . . . . . . . . . . . . . . . . .   9
    3.3. The Script-URI . . . . . . . . . . . . . . . . . . . . .   9
    3.4. Execution  . . . . . . . . . . . . . . . . . . . . . . .  10

4.  The CGI Request . . . . . . . . . . . . . . . . . . . . . . .  10
    4.1. Request Meta-Variables . . . . . . . . . . . . . . . . .  10
         4.1.1.  AUTH_TYPE. . . . . . . . . . . . . . . . . . . .  11
         4.1.2.  CONTENT_LENGTH . . . . . . . . . . . . . . . . .  12
         4.1.3.  CONTENT_TYPE . . . . . . . . . . . . . . . . . .  12
         4.1.4.  GATEWAY_INTERFACE. . . . . . . . . . . . . . . .  13
         4.1.5.  PATH_INFO. . . . . . . . . . . . . . . . . . . .  13
         4.1.6.  PATH_TRANSLATED. . . . . . . . . . . . . . . . .  14
         4.1.7.  QUERY_STRING . . . . . . . . . . . . . . . . . .  15
         4.1.8.  REMOTE_ADDR. . . . . . . . . . . . . . . . . . .  15
         4.1.9.  REMOTE_HOST. . . . . . . . . . . . . . . . . . .  16
         4.1.10. REMOTE_IDENT . . . . . . . . . . . . . . . . . .  16
         4.1.11. REMOTE_USER. . . . . . . . . . . . . . . . . . .  16
         4.1.12. REQUEST_METHOD . . . . . . . . . . . . . . . . .  17
         4.1.13. SCRIPT_NAME. . . . . . . . . . . . . . . . . . .  17
         4.1.14. SERVER_NAME. . . . . . . . . . . . . . . . . . .  17
         4.1.15. SERVER_PORT. . . . . . . . . . . . . . . . . . .  18
         4.1.16. SERVER_PROTOCOL. . . . . . . . . . . . . . . . .  18
         4.1.17. SERVER_SOFTWARE. . . . . . . . . . . . . . . . .  19
         4.1.18. Protocol-Specific Meta-Variables . . . . . . . .  19
    4.2. Request Message-Body . . . . . . . . . . . . . . . . . .  20
    4.3. Request Methods  . . . . . . . . . . . . . . . . . . . .  20
         4.3.1.  GET. . . . . . . . . . . . . . . . . . . . . . .  20
         4.3.2.  POST . . . . . . . . . . . . . . . . . . . . . .  21
         4.3.3.  HEAD . . . . . . . . . . . . . . . . . . . . . .  21
         4.3.4.  Protocol-Specific Methods. . . . . . . . . . . .  21
    4.4. The Script Command Line. . . . . . . . . . . . . . . . .  21

5.  NPH Scripts . . . . . . . . . . . . . . . . . . . . . . . . .  22
    5.1. Identification . . . . . . . . . . . . . . . . . . . . .  22
    5.2. NPH Response . . . . . . . . . . . . . . . . . . . . . .  22

6.  CGI Response. . . . . . . . . . . . . . . . . . . . . . . . .  23
    6.1. Response Handling. . . . . . . . . . . . . . . . . . . .  23
    6.2. Response Types . . . . . . . . . . . . . . . . . . . . .  23
         6.2.1.  Document Response. . . . . . . . . . . . . . . .  23
         6.2.2.  Local Redirect Response. . . . . . . . . . . . .  24
         6.2.3.  Client Redirect Response . . . . . . . . . . . .  24
         6.2.4.  Client Redirect Response with Document . . . . .  24
    6.3. Response Header Fields . . . . . . . . . . . . . . . . .  25
         6.3.1.  Content-Type . . . . . . . . . . . . . . . . . .  25
         6.3.2.  Location . . . . . . . . . . . . . . . . . . . .  26
         6.3.3.  Status . . . . . . . . . . . . . . . . . . . . .  26
         6.3.4.  Protocol-Specific Header Fields. . . . . . . . .  27
         6.3.5.  Extension Header Fields. . . . . . . . . . . . .  27
    6.4. Response Message-Body. . . . . . . . . . . . . . . . . .  28

7.  System Specifications . . . . . . . . . . . . . . . . . . . .  28
    7.1. AmigaDOS . . . . . . . . . . . . . . . . . . . . . . . .  28
    7.2. UNIX . . . . . . . . . . . . . . . . . . . . . . . . . .  28
    7.3. EBCDIC/POSIX . . . . . . . . . . . . . . . . . . . . . .  29

8.  Implementation. . . . . . . . . . . . . . . . . . . . . . . .  29
    8.1. Recommendations for Servers. . . . . . . . . . . . . . .  29
    8.2. Recommendations for Scripts. . . . . . . . . . . . . . .  30

9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
    9.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . .  30
    9.2. Header Fields Containing Sensitive Information . . . . .  31
    9.3. Data Privacy . . . . . . . . . . . . . . . . . . . . . .  31
    9.4. Information Security Model . . . . . . . . . . . . . . .  31
    9.5. Script Interference with the Server. . . . . . . . . . .  31
    9.6. Data Length and Buffering Considerations . . . . . . . .  32
    9.7. Stateless Processing . . . . . . . . . . . . . . . . . .  32
    9.8. Relative Paths . . . . . . . . . . . . . . . . . . . . .  33
    9.9. Non-parsed Header Output . . . . . . . . . . . . . . . .  33

10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  33

11. References. . . . . . . . . . . . . . . . . . . . . . . . . .  33
    11.1. Normative References. . . . . . . . . . . . . . . . . .  33
    11.2. Informative References. . . . . . . . . . . . . . . . .  34

12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  35

13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  36

1. Introduction ✨

1.1. Purpose 💖

The Common Gateway Interface (CGI) [22] lets an HTTP [1], [4] server and a CGI script share the job of responding to client requests. The client request is made up of a Uniform Resource Identifier (URI) [11], a request method, and various ancillary information about the request that the transport protocol provides 🎀

CGI defines abstract parameters called meta-variables, which describe a client's request. Together with a concrete programmer interface, this gives you a platform-independent interface between the script and the HTTP server 🦋

The server handles the connection, data transfer, transport and network issues for the client request. The CGI script handles the application stuff, like data access and document processing 💅

1.2. Requirements 🔥

Okay so the key words in this document are 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' and 'OPTIONAL'. They're to be read the way BCP 14, RFC 2119 [3] describes 🫶

An implementation is not compliant if it fails to satisfy one or more of the 'must' requirements for the protocols it implements. An implementation that satisfies all of the 'must' and all of the 'should' requirements for its features is said to be 'unconditionally compliant'. One that satisfies all of the 'must' requirements but not all of the 'should' requirements for its features is said to be 'conditionally compliant' 👑

1.3. Specifications 🌈

Not every function and feature of CGI is defined in the main part of this spec. These phrases are used to describe the features that aren't specified 🧚

'system-defined'

The feature may differ between systems, but must be the same for different implementations using the same system. A system will usually identify a class of operating systems. Some systems are defined in section 7 of this document. New systems may be defined by new specifications without revision of this document 🍓

'implementation-defined'

The behaviour of the feature may vary from implementation to implementation. A particular implementation must document its behaviour 🌸

1.4. Terminology 💜

This spec uses a lot of terms defined in the HTTP/1.1 specification [4]. However, the following terms are used here in a sense that may not match their definitions in that document, or their common meaning. Read carefully, bestie 🙈

'meta-variable'

A named parameter that carries information from the server to the script. It isn't necessarily a variable in the operating system's environment, although that's the most common implementation ✨

'script'

The software that the server invokes according to this interface. It doesn't need to be a standalone program. It could be a dynamically-loaded or shared library, or even a subroutine in the server. It might be a set of statements interpreted at run-time, the way the term 'script' is often understood, but that isn't a requirement. Within this specification, the term has the broader definition stated here 💖

'server'

The application program that invokes the script in order to service requests from the client 🎀

2. Notational Conventions and Generic Grammar 🧚

2.1. Augmented BNF 🎀

okay so every mechanism in this doc gets described in BOTH prose and an augmented Backus-Naur Form, which is giving RFC 822 [13] vibes 💅 unless it says otherwise, the elements are case-sensitive, so keep that in mind bestie ✨ here's the toolkit:

  • name = definition: the rule name and its definition are separated by the equals character (=). Whitespace only matters in that continuation lines of a definition are indented 🌸
  • "literal": double quotation marks (") wrap literal text. A literal quotation mark gets wrapped in angle-brackets (< and >) instead 🦋
  • rule1 | rule2: alternatives are separated by a vertical bar (|) 💜
  • (rule1 rule2 rule3): anything in parentheses gets treated as one single element 🧚
  • *rule: a rule with an asterisk (*) in front can show up zero or more times. The full form is n*m rule, meaning at least n and at most m occurrences. n and m are optional decimal values, defaulting to 0 and infinity respectively 🍓
  • [rule]: anything in square brackets is optional, the same as *1 rule 🌈
  • N rule: a rule with a decimal number in front shows up exactly N times. It's the same as N*N rule 👑

2.2. Basic Rules ✨

this spec uses a BNF-like grammar defined in terms of characters, and that's lowkey different from a lot of specs that define the bytes a protocol allows 🫶 here, every literal in the grammar matches the character it represents. How those characters get stored in bits and bytes inside a system is either system-defined or specified in the particular context. The one exception is the rule OCTET, which we'll get to 💖

these basic parsing rules get used all over the spec 💅

   alpha         = lowalpha | hialpha
   lowalpha      = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                   "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                   "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                   "y" | "z"
   hialpha       = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                   "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                   "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                   "Y" | "Z"

   digit         = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                   "8" | "9"
   alphanum      = alpha | digit
   OCTET         = <any 8-bit byte>
   CHAR          = alpha | digit | separator | "!" | "#" | "$" |
                   "%" | "&" | "'" | "*" | "+" | "-" | "." | "`" |
                   "^" | "_" | "{" | "|" | "}" | "~" | CTL
   CTL           = <any control character>
   SP            = <space character>
   HT            = <horizontal tab character>
   NL            = <newline>
   LWSP          = SP | HT | NL
   separator     = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
                   "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
                   "}" | SP | HT
   token         = 1*<any CHAR except CTLs or separators>
   quoted-string = <"> *qdtext <">
   qdtext        = <any CHAR except <"> and CTLs but including LWSP>
   TEXT          = <any printable character>

ngl the NL thing is a whole vibe 🌸 newline (NL) doesn't have to be one single control character. It can be a sequence of control characters. And a system MAY define TEXT as a bigger set of characters than <any CHAR excluding CTLs but including LWSP>. Iconic flexibility 🦋

2.3. URL Encoding 🌷

some variables and constructs in here get described as being 'URL-encoded'. That encoding is described in section 2 of RFC 2396 [2]. In a URL-encoded string, an escape sequence is a percent character (%) followed by two hexadecimal digits, and those two digits form an octet. The escape sequence stands for the graphic character whose code is that octet in the US-ASCII [9] coded character set, if one exists. Right now the URI syntax has no way to say which character set the non-ASCII codes belong to, so CGI just handles that on an ad-hoc basis 🙈

some unsafe (reserved) characters can mean something different when they're encoded. Which characters count as unsafe depends on the context. For the authoritative take, check section 2 of RFC 2396 [2], updated by RFC 2732 [7] 📚 Reserved characters usually give the string its syntactic structure, like acting as field separators. In every case, the string gets processed for any reserved characters first, and then the data can be URL-decoded by swapping % escape sequences for their character values ✨

to URL-encode a string, every reserved and forbidden character gets replaced with its matching % escape sequence. Then the string can be used to build a URI. The reserved characters change from context to context, but they always come from this set:

   reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" |
              "," | "[" | "]"

the last two characters got added by RFC 2732 [7] 🎀 In any particular context, only a subset of these is reserved. The other characters from this set MUST NOT be encoded when a string is URL-encoded in that context. Here are the other basic rules for URI syntax:

   hex        = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b"
                | "c" | "d" | "e" | "f"
   escaped    = "%" hex hex
   unreserved = alpha | digit | mark
   mark       = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

3. Invoking the Script ✨

3.1. Server Responsibilities 💅

the server is basically an application gateway, bestie 🚪 It gets the request from the client, picks a CGI script to handle it, turns the client request into a CGI request, runs the script, and then turns the CGI response back into a response for the client. While it's processing the client request, the server is responsible for implementing any protocol or transport level authentication and security 🔐 The server MAY also work in a 'non-transparent' way, changing the request or response to offer some extra service, like media type transformation or protocol reduction 🦋

the server MUST do the translations and protocol conversions on the client request data that this spec needs. And even if the CGI script doesn't follow this spec, the server still owes the client conformance to the relevant network protocol 💖

if the server is applying authentication to the request, it MUST NOT execute the script unless the request passes all of the defined access controls 🙅‍♀️

3.2. Script Selection 🌸

the server works out which CGI script to run based on a generic-form URI the client sent. This URI has a hierarchical path with components separated by "/". For any given request, the server matches all of the path, or a leading part of it, to one individual script. That puts the script at a specific spot in the path hierarchy. Whatever path is left over, if there is any, is a resource or sub-resource identifier that the script gets to interpret 🧚

info about how the path got split is available to the script in the meta-variables, which we'll cover below 📝 Support for non-hierarchical URI schemes is outside the scope of this spec, so we're not going there 🙈

3.3. The Script-URI 🔗

the mapping from the client request URI to the chosen script is defined by the particular server implementation and its configuration 🎀 The server may let the script be identified with a bunch of different URI path hierarchies, so it's allowed to swap the URI for another member of that set while it's processing and generating the meta-variables. The server

  1. MAY preserve the URI in the particular client request; or
  2. it MAY select a canonical URI from the set of possible values for each script; or
  3. it can implement any other selection of URI from the set.

from the meta-variables generated this way, a URI called the 'Script-URI' can be constructed 🌈 This MUST have the property that if the client had accessed this URI instead, the script would have been executed with the same values for the SCRIPT_NAME, PATH_INFO and QUERY_STRING meta-variables. The Script-URI has the structure of a generic URI as defined in section 3 of RFC 2396 [2], except that object parameters and fragment identifiers are not permitted 🙅‍♀️ The different parts of the Script-URI are defined by some of the meta-variables (see below):

   script-URI = <scheme> "://" <server-name> ":" <server-port>
                <script-path> <extra-path> "?" <query-string>

where <scheme> is found from SERVER_PROTOCOL, and <server-name>, <server-port> and <query-string> are the values of their respective meta-variables. The SCRIPT_NAME and PATH_INFO values, URL-encoded with ";", "=" and "?" reserved, give <script-path> and <extra-path> 💜

see section 4.1.5 for more on the PATH_INFO meta-variable ✨

the scheme and the protocol aren't identical, because the scheme identifies the access method as well as the application protocol 🔒 For example, a resource accessed using Transport Layer Security (TLS) [14] would have a request URI with a scheme of https when using the HTTP protocol [19]. CGI/1.1 doesn't provide a generic way for the script to rebuild this, so the Script-URI as defined includes the base protocol being used. However, a script MAY make use of scheme-specific meta-variables to better work out the URI scheme 🧠

also, this definition lets you build URIs that would invoke the script with any permitted values for the path-info or query-string, just by changing the right components 🍓

3.4. Execution 🚀

the script gets invoked in a system-defined manner. Unless specified otherwise, the file containing the script runs as an executable program 💻 The server prepares the CGI request as described in section 4. That means the request meta-variables (which the script can use right away when it runs) and the request message data. The request data doesn't have to be available immediately, so the script can start running before the server has gotten all of that data from the client ⏳ The response from the script goes back to the server as described in sections 5 and 6 🎁

if there's an error condition, the server can interrupt or terminate script execution at any time and without warning 😭 That could happen, for example, during a transport failure between the server and the client, so the script SHOULD be prepared to handle abnormal termination 🫶

4. The CGI Request 📬

info about a request comes from two different sources: the request meta-variables and any associated message-body 💖

4.1. Request Meta-Variables

Okay bestie, meta-variables are the request details the server passes to the script ✨ The script reads them in a system-defined way, and the names are case-insensitive, so you can never have two variables that only differ by capitalization 💅 We write them in capitals with underscores, but a particular system can pick its own style 🎀

meta-variable-name = "AUTH_TYPE" | "CONTENT_LENGTH" |
                     "CONTENT_TYPE" | "GATEWAY_INTERFACE" |
                     "PATH_INFO" | "PATH_TRANSLATED" |
                     "QUERY_STRING" | "REMOTE_ADDR" |
                     "REMOTE_HOST" | "REMOTE_IDENT" |
                     "REMOTE_USER" | "REQUEST_METHOD" |
                     "SCRIPT_NAME" | "SERVER_NAME" |
                     "SERVER_PORT" | "SERVER_PROTOCOL" |
                     "SERVER_SOFTWARE" | scheme |
                     protocol-var-name | extension-var-name
protocol-var-name  = ( protocol | scheme ) "_" var-name
scheme             = alpha *( alpha | digit | "+" | "-" | "." )
var-name           = token
extension-var-name = token

Meta-variables named after a scheme, and names that start with a protocol or scheme name (like HTTP_ACCEPT), are defined too 🦋 The number and meaning of these variables may change independently of this specification. (See also section 4.1.18.) 🌸

The server MAY set additional implementation-defined extension meta-variables, and their names SHOULD be prefixed with "X_" 🧚

Here's the tea: this spec doesn't tell apart a zero-length (NULL) value from a missing one 🙈 For example, a script can't tell the difference between http://host/script and http://host/script?, because QUERY_STRING would be NULL in both cases.

meta-variable-value = "" | 1*<TEXT, CHAR or tokens of value>

An optional meta-variable can be left out (unset) if its value is NULL 💖 Meta-variable values MUST be treated as case-sensitive unless noted otherwise, and the representation of characters is system-defined, so the server MUST convert values to that representation ✨

4.1.1. AUTH_TYPE

AUTH_TYPE tells the script which mechanism the server used to authenticate the user 🔐 It holds a case-insensitive value defined by the client protocol or the server implementation.

For HTTP, if the client request needed authentication for external access, the server MUST set this variable from the 'auth-scheme' token in the request Authorization header field 🎀

AUTH_TYPE      = "" | auth-scheme
auth-scheme    = "Basic" | "Digest" | extension-auth
extension-auth = token

HTTP access authentication schemes are described in RFC 2617 [5] 📚

4.1.2. CONTENT_LENGTH

CONTENT_LENGTH holds the size of the message-body attached to the request (if there is one), as a decimal number of octets. If no data is attached, it's NULL (or unset) 💅

CONTENT_LENGTH = "" | 1*digit

The server MUST set this meta-variable if and only if the request comes with a message-body entity 🫶 The CONTENT_LENGTH value must reflect the length of the message-body after the server has removed any transfer-codings or content-codings. 🍓

4.1.3. CONTENT_TYPE

If the request includes a message-body, CONTENT_TYPE is set to the Internet Media Type [6] of that message-body 🌈

CONTENT_TYPE = "" | media-type
media-type   = type "/" subtype *( ";" parameter )
type         = token
subtype      = token
parameter    = attribute "=" value
attribute    = token
value        = token | quoted-string

The type, subtype and parameter attribute names aren't case-sensitive, but parameter values might be 🙃 Media types and how they're used in HTTP are described in section 3.7 of the HTTP/1.1 specification [4] ✨

There's no default value for this variable. If and only if it's unset, the script MAY try to work out the media type from the data it received. If the type is still unknown, the script MAY assume application/octet-stream, or it may reject the request with an error (as described in section 6.3.3) 💀

Each media-type defines a set of optional and mandatory parameters. This can include a charset parameter, with a case-insensitive value that defines the coded character set for the message-body 🦋 If the charset parameter is left out, the default should be worked out using whichever of these rules applies first:

  1. There MAY be a system-defined default charset for some media-types.
  2. The default for media-types of type "text" is ISO-8859-1 [4].
  3. Any default defined in the media-type specification.
  4. The default is US-ASCII.

The server MUST set this meta-variable if an HTTP Content-Type field is present in the client request header. If the server gets a request with an attached entity but no Content-Type header field, it MAY try to figure out the correct content type. Otherwise, it should omit this meta-variable 👑

4.1.4. GATEWAY_INTERFACE

GATEWAY_INTERFACE MUST be set to the dialect of CGI the server is using to talk to the script 🧚 Syntax:

GATEWAY_INTERFACE = "CGI" "/" 1*digit "." 1*digit

The major and minor numbers are treated as separate integers, so each one can go higher than a single digit 🔥 That means CGI/2.4 is a lower version than CGI/2.13, which in turn is lower than CGI/12.3 😭 Leading zeros MUST be ignored by the script and MUST NOT be generated by the server.

This document defines the 1.1 version of the CGI interface 🌸

4.1.5. PATH_INFO

PATH_INFO specifies a path for the CGI script to interpret 🦋 It identifies the resource or sub-resource the script should return, and it's taken from the part of the URI path that comes after the bit identifying the script itself. Unlike a URI path, PATH_INFO is not URL-encoded, and it can't contain path-segment parameters. A PATH_INFO of "/" represents a single void path segment 🎀

PATH_INFO = "" | ( "/" path )
path      = lsegment *( "/" lsegment )
lsegment  = *lchar
lchar     = <any TEXT or CTL except "/">

The value is case-sensitive, and the server MUST preserve the case of the path exactly as it appeared in the request URI 💖 The server MAY impose restrictions and limits on what values it allows for PATH_INFO, and MAY reject the request with an error if it runs into any values it finds objectionable. That MAY include any requests that would end up with an encoded "/" being decoded into PATH_INFO, since that could mean losing information the script needs 🙈 Similarly, how non US-ASCII characters in the path are treated is system-defined.

Once URL-encoded, the PATH_INFO string forms the extra-path component of the Script-URI (see section 3.3), which comes after the SCRIPT_NAME part of that path 🧚

4.1.6. PATH_TRANSLATED

PATH_TRANSLATED is worked out by taking the PATH_INFO value, parsing it as a local URI in its own right, and doing whatever virtual-to-physical translation is needed to map it onto the server's document repository structure 🗺️ The set of characters allowed in the result is system-defined.

PATH_TRANSLATED = *<any character>

This is the file location that would be accessed by a request for

<scheme> "://" <server-name> ":" <server-port> <extra-path>

where <scheme> is the scheme of the original client request, and <extra-path> is a URL-encoded version of PATH_INFO, with ";", "=" and "?" reserved. For example, a request like this:

http://somehost.com/cgi-bin/somescript/this%2eis%2epath%3binfo

would result in a PATH_INFO value of:

/this.is.the.path;info

An internal URI is built from the scheme, the server location and the URL-encoded PATH_INFO:

http://somehost.com/this.is.the.path%3binfo

That then gets translated to a location in the server's document repository, which might be a filesystem path something like this:

/usr/local/www/htdocs/this.is.the.path;info

The value of PATH_TRANSLATED is the result of that translation ✨

It's derived this way whether or not it maps to a valid repository location 💅 The server MUST preserve the case of the extra-path segment, unless the underlying repository supports case-insensitive names. If the repository is only case-aware, case-preserving, or case-blind with regard to document names, the server is not required to keep the case of the original segment through the translation.

The translation algorithm the server uses to derive PATH_TRANSLATED is implementation-defined, so CGI scripts that use this variable may have limited portability 😬

The server SHOULD set this meta-variable if the request URI includes a path-info component. If PATH_INFO is NULL, then PATH_TRANSLATED MUST be set to NULL (or unset) 🌈

4.1.7. QUERY_STRING

QUERY_STRING holds a URL-encoded search or parameter string 🔍 It gives the CGI script extra info to narrow down or tweak the document it returns.

The URL syntax for a search string is described in section 3 of RFC 2396 [2]. The QUERY_STRING value is case-sensitive ✨

QUERY_STRING = query-string
query-string = *uric
uric         = reserved | unreserved | escaped

When parsing and decoding the query string, the details of parsing, reserved characters and support for non US-ASCII characters depend on the context 🫶 For example, form submission from an HTML document [18] uses application/x-www-form-urlencoded encoding, where the characters "+", "&" and "=" are reserved, and the ISO 8859-1 encoding may be used for non US-ASCII characters.

The QUERY_STRING value provides the query-string part of the Script-URI (see section 3.3) 🦋

The server MUST set this variable. If the Script-URI doesn't include a query component, QUERY_STRING MUST be defined as an empty string ("") 💜

4.1.8. REMOTE_ADDR

REMOTE_ADDR MUST be set to the network address of the client sending the request to the server 📍

REMOTE_ADDR  = hostnumber
hostnumber   = ipv4-address | ipv6-address
ipv4-address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
ipv6-address = hexpart [ ":" ipv4-address ]
hexpart      = hexseq | ( [ hexseq ] "::" [ hexseq ] )
hexseq       = 1*4hex *( ":" 1*4hex )

The format of an IPv6 address is described in RFC 3513 [15] 🌸

4.1.9. REMOTE_HOST

REMOTE_HOST holds the fully qualified domain name of the client sending the request, if it's available, and NULL otherwise 🏠 Fully qualified domain names take the form described in section 3.5 of RFC 1034 [17] and section 2.1 of RFC 1123 [12]. Domain names are not case sensitive.

REMOTE_HOST   = "" | hostname | hostnumber
hostname      = *( domainlabel "." ) toplabel [ "." ]
domainlabel   = alphanum [ *alphahypdigit alphanum ]
toplabel      = alpha [ *alphahypdigit alphanum ]
alphahypdigit = alphanum | "-"

The server SHOULD set this variable. If the hostname isn't available, whether for performance reasons or otherwise, the server MAY substitute the REMOTE_ADDR value 🫧

4.1.10. REMOTE_IDENT 🎀

okay so REMOTE_IDENT is lowkey a fun one 🦋 The REMOTE_IDENT variable MAY be used to provide identity info that was reported about the connection by an RFC 1413 [20] request to the remote agent, if it's available. The server may choose not to support this feature, or not to request the data for efficiency reasons, or not to return available identity data.

REMOTE_IDENT = *TEXT

The data returned may be used for authentication purposes, but the level of trust reposed in it should be minimal. Be careful with this one, bestie 🫶

4.1.11. REMOTE_USER 👑

the REMOTE_USER variable gives you a user identification string that the client supplied as part of user authentication 💅

REMOTE_USER = *TEXT

If the client request required HTTP Authentication [5] (for example, the AUTH_TYPE meta-variable is set to "Basic" or "Digest"), then the value of the REMOTE_USER meta-variable MUST be set to the user-ID supplied. no skipping this, it's a must!! 😭

4.1.12. REQUEST_METHOD ✨

the REQUEST_METHOD meta-variable MUST be set to the method that should be used by the script to process the request, as described in section 4.3. it's giving main character energy 🌸

REQUEST_METHOD   = method
method           = "GET" | "POST" | "HEAD" | extension-method
extension-method = "PUT" | "DELETE" | token

The method is case sensitive, so capitalization matters here 🙈 The HTTP methods are described in section 5.1.1 of the HTTP/1.0 specification [1] and section 5.1.1 of the HTTP/1.1 specification [4].

4.1.13. SCRIPT_NAME 🧚

the SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded) that could identify the CGI script (rather than the script's output). the syntax is the same as for PATH_INFO (section 4.1.5) 🦋

SCRIPT_NAME = "" | ( "/" path )

The leading "/" is not part of the path. It is optional if the path is NULL; however, the variable MUST still be set in that case. ngl this is a sneaky little detail 💀

The SCRIPT_NAME string forms some leading part of the path component of the Script-URI, derived in some implementation-defined manner. No PATH_INFO segment (see section 4.1.5) is included in the SCRIPT_NAME value. 🎀

4.1.14. SERVER_NAME 💖

the SERVER_NAME variable MUST be set to the name of the server host that the client request is directed to. it's a case-insensitive hostname or network address, and it forms the host part of the Script-URI 🍓

SERVER_NAME = server-name
server-name = hostname | ipv4-address | ( "[" ipv6-address "]" )

A deployed server can have more than one possible value for this variable, where several HTTP virtual hosts share the same IP address. In that case, the server would use the contents of the request's Host header field to select the correct virtual host. it's giving multiple personalities, iykyk 🌈

4.1.15. SERVER_PORT 🔥

the SERVER_PORT variable MUST be set to the TCP/IP port number that this request was received on from the client. this value is used in the port part of the Script-URI 💅

SERVER_PORT = server-port
server-port = 1*digit

Note that this variable MUST be set, even if the port is the default port for the scheme and could otherwise be omitted from a URI. Not me forgetting this one lol 🙈

4.1.16. SERVER_PROTOCOL 👑

the SERVER_PROTOCOL variable MUST be set to the name and version of the application protocol used for this CGI request. This MAY differ from the protocol version the server uses in its communication with the client. the vibes are different, and that's okay ✨

SERVER_PROTOCOL   = HTTP-Version | "INCLUDED" | extension-version
HTTP-Version      = "HTTP" "/" 1*digit "." 1*digit
extension-version = protocol [ "/" 1*digit "." 1*digit ]
protocol          = token

Here, 'protocol' defines the syntax of some of the information passing between the server and the script (the 'protocol-specific' features). It is not case sensitive and is usually written in upper case. The protocol is not the same as the scheme part of the script URI, which defines the overall access mechanism the client uses to communicate with the server. For example, a request that reaches the script with a protocol of "HTTP" may have used an "https" scheme. the way that these are separate things is so iconic 🧚

A well-known value for SERVER_PROTOCOL that the server MAY use is "INCLUDED", which signals that the current document is being included as part of a composite document, rather than being the direct target of the client request. The script should treat this as an HTTP/1.0 request. 🦋

4.1.17. SERVER_SOFTWARE 🌸

the SERVER_SOFTWARE meta-variable MUST be set to the name and version of the information server software making the CGI request (and running the gateway). It SHOULD be the same as the server description reported to the client, if there is one 💜

SERVER_SOFTWARE = 1*( product | comment )
product         = token [ "/" product-version ]
product-version = token
comment         = "(" *( ctext | comment ) ")"
ctext           = <any TEXT excluding "(" and ")">

4.1.18. Protocol-Specific Meta-Variables 🌈

okay so this is where it gets spicy 🌶️ The server SHOULD set meta-variables specific to the protocol and scheme for the request. Interpreting protocol-specific variables depends on the protocol version in SERVER_PROTOCOL. The server MAY set a meta-variable with the name of the scheme to a non-NULL value if the scheme is not the same as the protocol. The presence of such a variable tells a script which scheme the request used. 🫶

Meta-variables whose names begin with "HTTP_" contain values read from the client request header fields, if the protocol used is HTTP. The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_", and has "HTTP_" prepended to give the meta-variable name. The header data can be presented as sent by the client, or it can be rewritten in ways that do not change its semantics. If multiple header fields with the same field-name are received, then the server MUST rewrite them as a single value having the same semantics. Similarly, a header field that spans multiple lines MUST be merged onto a single line. The server MUST, if necessary, change the representation of the data (for example, the character set) to be appropriate for a CGI meta-variable. 💅

The server is not required to create meta-variables for all the header fields that it receives. In particular, it SHOULD remove any header fields carrying authentication information, such as 'Authorization', or that are available to the script in other variables, such as 'Content-Length' and 'Content-Type'. The server MAY remove header fields that relate solely to client-side communication issues, such as 'Connection'. lowkey the server is cleaning up its closet 🧹✨

4.2. Request Message-Body 🎀

the request data is accessed by the script in a system-defined method. Unless defined otherwise, this will be by reading the 'standard input' file descriptor or file handle. 🦋

Request-Data   = [ request-body ] [ extension-data ]
request-body   = <CONTENT_LENGTH>OCTET
extension-data = *OCTET

A request-body is supplied with the request if the CONTENT_LENGTH is not NULL. The server MUST make at least that many bytes available for the script to read. The server MAY signal an end-of-file condition after CONTENT_LENGTH bytes have been read, or it MAY supply extension data. Therefore, the script MUST NOT attempt to read more than CONTENT_LENGTH bytes, even if more data is available. However, it is not obliged to read any of the data. the script gets to choose, and that's so slay 💖

For non-parsed header (NPH) scripts (section 5), the server SHOULD attempt to ensure that the data supplied to the script is precisely as supplied by the client and is unaltered by the server. 🫶

As transfer-codings are not supported on the request-body, the server MUST remove any such codings from the message-body and recalculate the CONTENT_LENGTH. If this is not possible (for example, because of large buffering requirements), the server SHOULD reject the client request. It MAY also remove content-codings from the message-body. bestie the server is basically doing a glow-up on the body 🌸

4.3. Request Methods 💜

The Request Method, as supplied in the REQUEST_METHOD meta-variable, identifies the processing method that the script should apply when producing a response. The script author can choose to implement the methods that are most appropriate for the particular application. If the script receives a request with a method it does not support, it SHOULD reject it with an error (see section 6.3.3). 🔥

4.3.1. GET 🧚

The GET method indicates that the script should produce a document based on the meta-variable values. By convention, the GET method is 'safe' and 'idempotent', and it SHOULD NOT have the significance of taking an action other than producing a document. The meaning of the GET method may be modified and refined by protocol-specific meta-variables. GET is the chill one, no drama 🌈

4.3.2. POST 🍓

The POST method is used to request that the script perform processing and produce a document based on the data in the request message-body, in addition to meta-variable values. A common use is form submission in HTML [18], intended to initiate processing by the script that has a permanent affect, such a change in a database. the stakes are high here 😭

The script MUST check the value of the CONTENT_LENGTH variable before reading the attached message-body, and SHOULD check the CONTENT_TYPE value before processing it. 💅

4.3.3. HEAD 🦋

The HEAD method requests that the script do sufficient processing to return the response header fields, without providing a response message-body. The script MUST NOT provide a response message-body for a HEAD request. If it does, then the server MUST discard the message-body when reading the response from the script. no body allowed, periodt 🙅‍♀️

4.3.4. Protocol-Specific Methods ✨

The script MAY implement any protocol-specific method, such as HTTP/1.1 PUT and DELETE. It SHOULD check the value of SERVER_PROTOCOL when doing so. 🌸

The server MAY decide that some methods are not appropriate or permitted for a script, and it may handle the methods itself or return an error to the client. 👑

4.4. The Script Command Line 🎀

Some systems support a method for supplying an array of strings to the CGI script. This is only used in the case of an 'indexed' HTTP query, which is identified by a 'GET' or 'HEAD' request with a URI query string that does not contain any unencoded "=" characters. For such a request, the server SHOULD treat the query-string as a search-string and parse it into words, using the rules below. 🧚

search-string = search-word *( "+" search-word )
search-word   = 1*schar
schar         = unreserved | escaped | xreserved
xreserved     = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "," |
                      "$"

After parsing, each search-word is URL-decoded, optionally encoded in a system-defined manner, and then added to the command line argument list. 💖

If the server cannot create any part of the argument list, then the server MUST NOT generate any command line information. For example, the number of arguments may be greater than operating system or server limits, or one of the words may not be representable as an argument. the server just says nope and that's the end of it 🙈

The script SHOULD check to see if the QUERY_STRING value contains an unencoded "=" character, and it SHOULD NOT use the command line arguments if it does. 🫶

5. NPH Scripts 🌈

5.1. Identification 💜

The server MAY support NPH (Non-Parsed Header) scripts. These are scripts to which the server passes all responsibility for response processing. 🔥

This specification provides no mechanism for an NPH script to be identified on the basis of its output data alone. By convention, therefore, any particular script can only ever provide output of one type (NPH or CGI), and hence the script itself is described as an 'NPH script'. A server with NPH support MUST provide an implementation-defined mechanism for identifying NPH scripts, perhaps based on the name or location of the script. okay the naming tea is important here ☕️🦋

5.2. NPH Response ✨

okay bestie, there MUST be a system-defined method for the script to send data back to the server or client 📮 and a script MUST always return some data, no exceptions 💅 Unless it's defined otherwise, this works exactly like it does for conventional CGI scripts 🎀

ngl, NPH scripts are only defined for HTTP client requests right now 🦋 So an (HTTP) NPH script MUST return a complete HTTP response message, which is described in section 6 of the HTTP specifications [1], [4] 🧚 The script MUST use the SERVER_PROTOCOL variable to figure out the right format for its response 🔥 It MUST also take account of any generic or protocol-specific meta-variables in the request, as the particular protocol specification might require 👑

The server MUST ensure the script output gets sent to the client unmodified 🫶 Note that this means the script has to use the correct character set (US-ASCII [9] and ISO 8859-1 [10] for HTTP) in its header fields 💜 The server SHOULD try to make sure the output goes straight to the client, with minimal internal buffering and no transport-visible buffering 🌸

Unless the implementation says otherwise, the script MUST NOT indicate in its response that the client can send further requests over the same connection 🙈

6. CGI Response 🎀

6.1. Response Handling 💖

A script MUST always provide a non-empty response, so there's a system-defined method for it to send that data back to the server. Unless defined otherwise, that's the 'standard output' file descriptor 📤

The script MUST check the REQUEST_METHOD variable when it processes the request and prepares its response 🔍

The server MAY implement a timeout period within which data must be received from the script ⏰ If a server implementation defines such a timeout and receives no data from a script within that period, the server MAY terminate the script process 💀

6.2. Response Types 🧁

The response is a message-header plus a message-body, separated by a blank line 📄 The message-header holds one or more header fields. The body may be NULL.

      generic-response = 1*header-field NL [ response-body ]

The script MUST return one of: a document response, a local redirect response, or a client redirect (with optional document) response. In the response definitions below, the order of header fields in a response is not significant (despite appearing so in the BNF). The header fields are defined in section 6.3.

      CGI-Response = document-response | local-redir-response |
                     client-redir-response | client-redirdoc-response

6.2.1. Document Response 📚

The CGI script can return a document to the user in a document response, with an optional error code showing the success status of the response.

      document-response = Content-Type [ Status ] *other-field NL
                          response-body

The script MUST return a Content-Type header field. A Status header field is optional, and status 200 'OK' is assumed if it's left out. The server MUST make any appropriate modifications to the script's output to ensure that the response to the client complies with the response protocol version.

6.2.2. Local Redirect Response 🔁

The CGI script can return a URI path and query-string ('local-pathquery') for a local resource in a Location header field. This tells the server to reprocess the request using the path specified.

      local-redir-response = local-Location NL

The script MUST NOT return any other header fields or a message-body, and the server MUST generate the response that it would have produced in response to a request containing the URL

      scheme "://" server-name ":" server-port local-pathquery

6.2.3. Client Redirect Response 🦋

The CGI script can return an absolute URI path in a Location header field, to tell the client to reprocess the request using the URI specified.

      client-redir-response = client-Location *extension-field NL

The script MUST not provide any other header fields, except for server-defined CGI extension fields. For an HTTP client request, the server MUST generate a 302 'Found' HTTP response message.

6.2.4. Client Redirect Response with Document 📎

The CGI script can return an absolute URI path in a Location header field together with an attached document, to tell the client to reprocess the request using the URI specified.

      client-redirdoc-response = client-Location Status Content-Type
                                 *other-field NL response-body

The Status header field MUST be supplied and MUST contain a status value of 302 'Found', or it MAY contain an extension-code, that is, another valid status code that means client redirection. The server MUST make any appropriate modifications to the script's output to ensure that the response to the client complies with the response protocol version.

6.3. Response Header Fields 🎀

The response header fields are either CGI or extension header fields to be interpreted by the server, or protocol-specific header fields to be included in the response returned to the client. At least one CGI field MUST be supplied; each CGI field MUST NOT appear more than once in the response. The response header fields have this syntax:

      header-field    = CGI-field | other-field
      CGI-field       = Content-Type | Location | Status
      other-field     = protocol-field | extension-field
      protocol-field  = generic-field
      extension-field = generic-field
      generic-field   = field-name ":" [ field-value ] NL
      field-name      = token
      field-value     = *( field-content | LWSP )
      field-content   = *( token | separator | quoted-string )

The field-name is not case sensitive. A NULL field value is equivalent to a field not being sent. Note that each header field in a CGI-Response MUST be specified on a single line; CGI/1.1 does not support continuation lines. Whitespace is permitted between the ":" and the field-value (but not between the field-name and the ":"), and also between tokens in the field-value.

6.3.1. Content-Type 💌

The Content-Type response field sets the Internet Media Type [6] of the entity body.

      Content-Type = "Content-Type:" media-type NL

If an entity body is returned, the script MUST supply a Content-Type field in the response. If it fails to do so, the server SHOULD NOT attempt to determine the correct content type. The value SHOULD be sent unmodified to the client, except for any charset parameter changes.

Unless it is otherwise system-defined, the default charset assumed by the client for text media-types is ISO-8859-1 if the protocol is HTTP and US-ASCII otherwise. Hence the script SHOULD include a charset parameter. See section 3.4.1 of the HTTP/1.1 specification [4] for a discussion of this issue.

6.3.2. Location 📍

The Location header field tells the server that the script is returning a reference to a document rather than an actual document (see sections 6.2.3 and 6.2.4). It's either an absolute URI (optionally with a fragment identifier), indicating that the client is to fetch the referenced document, or a local URI path (optionally with a query string), indicating that the server is to fetch the referenced document and return it to the client as the response.

      Location        = local-Location | client-Location
      client-Location = "Location:" fragment-URI NL
      local-Location  = "Location:" local-pathquery NL
      fragment-URI    = absoluteURI [ "#" fragment ]
      fragment        = *uric
      local-pathquery = abs-path [ "?" query-string ]
      abs-path        = "/" path-segments
      path-segments   = segment *( "/" segment )
      segment         = *pchar
      pchar           = unreserved | escaped | extra
      extra           = ":" | "@" | "&" | "=" | "+" | "$" | ","

The syntax of an absoluteURI is incorporated into this document from that specified in RFC 2396 [2] and RFC 2732 [7]. A valid absoluteURI always starts with the name of scheme followed by ":"; scheme names start with a letter and continue with alphanumerics, "+", "-" or ".". The local URI path and query must be an absolute path, and not a relative path or NULL, and hence must start with a "/".

Note that any message-body attached to the request (such as for a POST request) may not be available to the resource that is the target of the redirect.

6.3.3. Status 🚦

The Status header field contains a 3-digit integer result code that shows how successfully the script handled the request.

      Status         = "Status:" status-code SP reason-phrase NL
      status-code    = "200" | "302" | "400" | "501" | extension-code
      extension-code = 3digit
      reason-phrase  = *TEXT

Status code 200 'OK' indicates success, and is the default value assumed for a document response. Status code 302 'Found' is used with a Location header field and response message-body. Status code 400 'Bad Request' may be used for an unknown request format, such as a missing CONTENT_TYPE. Status code 501 'Not Implemented' may be returned by a script if it receives an unsupported REQUEST_METHOD.

Other valid status codes are listed in section 6.1.1 of the HTTP specifications [1], [4], and also the IANA HTTP Status Code Registry [8] and MAY be used in addition to or instead of the ones listed above. The script SHOULD check the value of SERVER_PROTOCOL before using HTTP/1.1 status codes. The script MAY reject with error 405 'Method Not Allowed' HTTP/1.1 requests made using a method it does not support.

Note that returning an error status code does not have to mean an error condition with the script itself. For example, a script that is invoked as an error handler by the server should return the code appropriate to the server's error condition.

The reason-phrase is a textual description of the error to be returned to the client for human consumption.

6.3.4. Protocol-Specific Header Fields 🧩

The script MAY return any other header fields that relate to the response message defined by the specification for the SERVER_PROTOCOL (HTTP/1.0 [1] or HTTP/1.1 [4]). The server MUST translate the header data from the CGI header syntax to the HTTP header syntax if these differ. For example, the character sequence for newline (such as UNIX's US-ASCII LF) used by CGI scripts may not be the same as that used by HTTP (US-ASCII CR followed by LF).

The script MUST NOT return any header fields that relate to client-side communication issues and could affect the server's ability to send the response to the client. The server MAY remove any such header fields returned by the client. It SHOULD resolve any conflicts between header fields returned by the script and header fields that it would otherwise send itself.

6.3.5. Extension Header Fields 🧪

There may be additional implementation-defined CGI header fields, whose field names SHOULD begin with "X-CGI-". The server MAY ignore (and delete) any unrecognised header fields with names beginning "X-CGI-" that are received from the script.

6.4. Response Message-Body 🎁

The response message-body is an attached document to be returned to the client by the server. The server MUST read all the data provided by the script, until the script signals the end of the message-body by way of an end-of-file condition. The message-body SHOULD be sent unmodified to the client, except for HEAD requests or any required transfer-codings, content-codings or charset conversions.

      response-body = *OCTET

7. System Specifications 💅

7.1. AmigaDOS 🦋

Meta-Variables okay so the meta-variables get passed to the script as environment variables with the same names 💖 The script reads them with the DOS library routine GetVar(). The flags argument SHOULD be 0. Case is ignored, but upper case is recommended for compatibility with case-sensitive systems, so just go upper case, bestie 🌸

The current working directory the script's current working directory gets set to the directory that holds the script 📁

Character set US-ASCII [9] is used for meta-variables, header fields and values. The newline (NL) sequence is LF, and servers SHOULD also accept CR LF as a newline ✨

7.2. UNIX 🌈

For UNIX compatible operating systems, these are the rules:

Meta-Variables same vibe as always: the meta-variables get passed as environment variables with identically named keys. The script reads them with the C library routine getenv() or the variable environ 🧚

The command line you get it through the argc and argv arguments to main(). Any characters that are 'active' in the Bourne shell get escaped with a backslash, so the words come through clean 🫶

The current working directory the current working directory for the script SHOULD be set to the directory containing the script 🗂️

Character set the US-ASCII character set [9] is used for meta-variables, header fields and CHAR values, but it excludes NUL 🚫 TEXT values use ISO-8859-1. The PATH_TRANSLATED value can contain any 8-bit byte except NUL. The newline (NL) sequence is LF, and servers should also accept CR LF as a newline 🍓

7.3. EBCDIC/POSIX 🎀

For POSIX compatible operating systems using the EBCDIC character set, these are the rules:

Meta-Variables the meta-variables get passed to the script as environment variables with identically named keys. They're accessed with the C library routine getenv() 💜

The command line accessed through the argc and argv arguments to main(). Any characters that are 'active' in the Bourne shell get escaped with a backslash 🐚

The current working directory the current working directory for the script SHOULD be set to the directory containing the script 📂

Character set the IBM1047 character set [21] is used, excluding NUL, for meta-variables, header fields, values, TEXT strings and the PATH_TRANSLATED value. The newline (NL) sequence is LF, and servers should also accept CR LF as a newline 🦋

media-type charset default the default charset value for text (and other implementation-defined) media types is IBM1047 🌸

8. Implementation 🛠️

8.1. Recommendations for Servers 🖥️

okay so the server and the CGI script don't have to handle URL paths the same way (the client URLs and the PATH_INFO data, respectively), but server authors may want them to match, and that's lowkey iconic 👑 So the server implementation should spell out its behaviour for these cases:

  1. define any restrictions on allowed path segments, in particular whether non-terminal NULL segments are permitted;
  2. define the behaviour for "." or ".." path segments; i.e., whether they are prohibited, treated as ordinary path segments or interpreted in accordance with the relative URL specification [2];
  3. define any limits of the implementation, including limits on path or search string lengths, and limits on the volume of header fields the server will parse.

8.2. Recommendations for Scripts 📜

if the script isn't going to process the PATH_INFO data, then it should reject the request with 404 Not Found if PATH_INFO is not NULL 🙅‍♀️

if you're processing the output of a form, check that CONTENT_TYPE is application/x-www-form-urlencoded [18] or multipart/form-data [16]. If CONTENT_TYPE is blank, the script can reject the request with a 415 'Unsupported Media Type' error, where supported by the protocol 💅

when you're parsing PATH_INFO, PATH_TRANSLATED or SCRIPT_NAME, the script should be careful of void path segments ("//") and special path segments ("." and ".."). They should either be removed from the path before use in OS system calls, or the request should be rejected with 404 'Not Found' 🧐

when returning header fields, the script should try to send the CGI header fields as soon as possible, and should send them before any HTTP header fields. This may help reduce the server's memory requirements 🧠✨

script authors, listen up 👀 The REMOTE_ADDR and REMOTE_HOST meta-variables (see sections 4.1.8 and 4.1.9) may not identify the ultimate source of the request. They identify the client for the immediate request to the server, and that client may be a proxy, gateway, or other intermediary acting on behalf of the actual source client 🙈

9. Security Considerations 🔐

Okay, this part is seriously important, bestie 😭 Read every word.

9.1. Safe Methods 🛡️

as discussed in the security considerations of the HTTP specifications [1], [4], the convention has been established that the GET and HEAD methods should be 'safe' and 'idempotent' (repeated requests have the same effect as a single request). See section 9.1 of RFC 2616 [4] for a full discussion 📚

9.2. Header Fields Containing Sensitive Information 🙊

some HTTP header fields may carry sensitive information, and the server should not pass that on to the script unless it's explicitly configured to do so. For example, if the server protects the script with the Basic authentication scheme, then the client sends an Authorization header field containing a username and password. The server validates this information, so it should not pass the password along via the HTTP_AUTHORIZATION meta-variable without careful consideration 🔑 This also applies to the Proxy-Authorization header field and the corresponding HTTP_PROXY_AUTHORIZATION meta-variable.

9.3. Data Privacy 🕵️‍♀️

confidential data in a request should go in a message-body as part of a POST request, and NOT in the URI or message headers 🙅‍♀️ On some systems, the environment used to pass meta-variables to a script may be visible to other scripts or users. Also, many existing servers, proxies and clients will permanently record the URI, where it might be visible to third parties. Yikes 😬

9.4. Information Security Model 🏰

for a client connection using TLS, the security model applies between the client and the server, and not between the client and the script. It's the server's job to handle the TLS session, so it's the server that gets authenticated to the client, not the CGI script 🪪

This specification provides no mechanism for the script to authenticate the server that invoked it. There is no enforced integrity on the CGI request and response messages 💔

9.5. Script Interference with the Server 🧨

the most common implementation of CGI invokes the script as a child process using the same user and group as the server process. It should therefore be ensured that the script cannot interfere with the server process, its configuration, documents or log files 🚧

if the script is executed by calling a function linked in to the server software (either at compile-time or run-time), then precautions should be taken to protect the core memory of the server, or to ensure that untrusted code cannot be executed 🫣

9.6. Data Length and Buffering Considerations 📦

this specification places no limits on the length of the message-body presented to the script. The script should not assume that statically allocated buffers of any size are sufficient to contain the entire submission at one time. Using a fixed length buffer without careful overflow checking may result in an attacker exploiting 'stack-smashing' or 'stack-overflow' vulnerabilities of the operating system 😱 The script may spool large submissions to disk or other buffering media, but a rapid succession of large submissions may result in denial of service conditions.

If the CONTENT_LENGTH of a message-body is larger than resource considerations allow, scripts should respond with an error status appropriate for the protocol version. Potentially applicable status codes include 503 'Service Unavailable' (HTTP/1.0 and HTTP/1.1), 413 'Request Entity Too Large' (HTTP/1.1), and 414 'Request-URI Too Large' (HTTP/1.1) 🙃

Similar considerations apply to the server's handling of the CGI response from the script. There is no limit on the length of the header or message-body returned by the script, so the server should not assume that statically allocated buffers of any size are sufficient to contain the entire response 🧺

9.7. Stateless Processing 🫧

the stateless nature of the Web makes each script execution and resource retrieval independent of all others, even when multiple requests make up a single conceptual Web transaction. Because of this, a script should not make any assumptions about the context of the user-agent submitting a request 🤷‍♀️ In particular, scripts should examine data obtained from the client and verify that it's valid, both in form and content, before allowing it to be used for sensitive purposes such as input to other applications, commands, or operating system services. These uses include (but are not limited to) system call arguments, database writes, dynamically evaluated source code, and input to billing or other secure processes. It's important that applications be protected from invalid input, regardless of whether the invalidity is the result of user error, logic error, or malicious action 🔥

Authors of scripts involved in multi-request transactions should be particularly cautious about validating the state information. Undesirable effects may result from the substitution of dangerous values for portions of the submission which might otherwise be presumed safe. This kind of subversion happens when alterations are made to data from a prior stage of the transaction that were not meant to be controlled by the client (e.g., hidden HTML form elements, cookies, embedded URLs, etc.) 🍪

9.8. Relative Paths 🧭

the server should be careful of ".." path segments in the request URI. These should be removed or resolved in the request URI before it is split into the script-path and extra-path. Alternatively, when the extra-path is used to find the PATH_TRANSLATED, care should be taken to avoid the path resolution from providing translated paths outside an expected path hierarchy 🚪

9.9. Non-parsed Header Output 📨

if a script returns a non-parsed header output, to be interpreted by the client in its native protocol, then the script must address all security considerations relating to that protocol. No skipping this one, bestie 🫶

10. Acknowledgements 🌟

This work is based on the original CGI interface that came out of discussions on the 'www-talk' mailing list. In particular, Rob McCool, John Franks, Ari Luotonen, George Phillips and Tony Sanders deserve special recognition for their efforts in defining and implementing the early versions of this interface 👑

This document has also benefited a lot from the comments and suggestions made by Chris Adie, Dave Kristol and Mike Meyer, plus David Morris, Jeremy Madea, Patrick McManus, Adam Donahue, Ross Patterson and Harald Alvestrand 🥹💖

11. References 📚

11.1. Normative References

Okay bestie, these are the must-reads 📚🎀 The docs this spec leans on hardest, so you really need them to get the full picture.

  • [1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
  • [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI) : Generic Syntax", RFC 2396, August 1998.
  • [3] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
  • [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
  • [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [7] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
  • [8] "HTTP Status Code Registry", http://www.iana.org/assignments/http-status-codes, IANA.
  • [9] "Information Systems -- Coded Character Sets -- 7-bit American Standard Code for Information Interchange (7-Bit ASCII)", ANSI INCITS.4-1986 (R2002).
  • [10] "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-1:1998.

11.2. Informative References

These ones are the background reading 🧚 Super useful for context, but the spec doesn't need them to work.

  • [11] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, June 1994.
  • [12] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
  • [13] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
  • [14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [15] Hinden R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
  • [16] Masinter, L., "Returning Values from Forms: multipart/form-data", RFC 2388, August 1998.
  • [17] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • [18] Raggett, D., Le Hors, A., and I. Jacobs, Eds., "HTML 4.01 Specification", W3C Recommendation December 1999, http://www.w3.org/TR/html401/.
  • [19] Rescola, E. "HTTP Over TLS", RFC 2818, May 2000.
  • [20] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
  • [21] IBM National Language Support Reference Manual Volume 2, SE09-8002-01, March 1990.
  • [22] "The Common Gateway Interface", http://hoohoo.ncsa.uiuc.edu/cgi/, NCSA, University of Illinois.

12. Authors' Addresses 🌸

Meet the authors! 💖 David Robinson and Ken A. L. Coar, both from The Apache Software Foundation. Slay the email game:

David Robinson The Apache Software Foundation

EMail: drtr@apache.org

Ken A. L. Coar The Apache Software Foundation

EMail: coar@apache.org

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society! 🌈🫶

📦 where this page comes from