Network Working Group
`Request for Comments: 3875
`Category: Informational
`
`D. Robinson
`The Apache Software Foundation
`K. Coar
`The Apache Software Foundation
`October 2004
`
`The Common Gateway Interface (CGI) Version 1.1
`
`Status of this Memo
`
`This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
`Distribution of this memo is unlimited.
`
`Copyright Notice
`
`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. Currently, the supported information servers are
`HTTP servers.
`
`The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the ‘current
`practice’ parameters of the ‘CGI/1.1’ interface developed and documented at the U.S. National Centre for Su-
`percomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other,
`similar systems.
`
`Robinson & Coar
`
`Informational
`
`[Page 1]
`
`Google Ex. 1009, pg 1
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`Table of Contents
`
`1
`
`Introduction
`. .
`1.1 Purpose . .
`1.2 Requirements .
`1.3 Specifications .
`1.4 Terminology .
`.
`
`. . .
`. .
`.
`. .
`.
`. .
`.
`
`. .
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`. . . .
`.
`. .
`.
`.
`. .
`.
`.
`. .
`.
`
`. . .
`.
`. . .
`.
`. . .
`.
`. . .
`.
`
`. . .
`.
`. . .
`.
`. . .
`.
`. . .
`.
`
`. . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . .
`
`2 Notational Conventions and Generic Grammar
`2.1 Augmented BNF .
`. .
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`2.2 Basic Rules .
`.
`. .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`2.3 URL Encoding . .
`. .
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`
`. . .
`. . .
`. . .
`
`.
`.
`.
`
`. . .
`. . .
`. . .
`
`. . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . .
`
`3 Invoking the Script
`3.1 Server Responsibilities .
`3.2 Script Selection . .
`. .
`.
`3.3 The Script-URI
`. .
`.
`.
`.
`3.4 Execution .
`.
`.
`. .
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`. . . . . . . . . . . . . . . . . . . . . .
`. . .
`.
`. . .
`.
`. . .
`.
`. .
`.
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . .
`. .
`.
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . .
`. .
`.
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . .
`
`4
`4
`4
`4
`5
`
`5
`5
`6
`7
`
`7
`7
`8
`8
`9
`
`9
`4 The CGI Request
`9
`. . . . . . . . . . . . . . . . . . . . . . . .
`.
`. . .
`.
`. . .
`. . .
`.
`.
`.
`.
`4.1 Request Meta-Variables .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 10
`. .
`. .
`. .
`. .
`. .
`.
`.
`.
`.
`4.1.1 AUTH_TYPE .
`.
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 11
`. .
`. .
`. .
`. .
`. .
`4.1.2 CONTENT_LENGTH .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 11
`. .
`. .
`. .
`. .
`. .
`4.1.3 CONTENT_TYPE .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 12
`. .
`. .
`4.1.4 GATEWAY_INTERFACE .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 12
`. .
`. .
`4.1.5
`PATH_INFO .
`.
`.
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 12
`. .
`. .
`4.1.6
`PATH_TRANSLATED .
`. .
`. .
`. .
`4.1.7 QUERY_STRING . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . 13
`4.1.8 REMOTE_ADDR .
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 14
`4.1.9 REMOTE_HOST . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 14
`4.1.10 REMOTE_IDENT .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 14
`4.1.11 REMOTE_USER . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 15
`4.1.12 REQUEST_METHOD .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 15
`4.1.13 SCRIPT_NAME . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 15
`4.1.14 SERVER_NAME .
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 15
`4.1.15 SERVER_PORT .
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 16
`4.1.16 SERVER_PROTOCOL . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . 16
`4.1.17 SERVER_SOFTWARE .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . 16
`4.1.18 Protocol-Specific Meta-Variables
`.
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 17
`4.2 Request Message-Body .
`.
`.
`.
`.
`.
`. .
`.
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . 17
`4.3 Request Methods .
`. .
`.
`.
`.
`.
`.
`.
`. .
`.
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . 18
`4.3.1 GET . .
`.
`.
`. .
`.
`.
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 18
`4.3.2
`POST .
`. .
`. . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 18
`4.3.3 HEAD . .
`. . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 18
`4.3.4
`Protocol-Specific Methods .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 18
`4.4 The Script Command Line .
`.
`.
`. . .
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 19
`
`Robinson & Coar
`
`Informational
`
`[Page 2]
`
`Google Ex. 1009, pg 2
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`5 NPH Scripts
`.
`. .
`5.1
`Identification .
`5.2 NPH Response . . .
`
`. .
`. .
`
`.
`.
`. .
`
`.
`. .
`. .
`. .
`. .
`. .
`.
`. .
`. .
`. .
`. .
`. .
`. .
`
`19
`. . . . . . . . . . 19
`.
`. . .
`.
`. . .
`. . .
`.
`. . .
`. .
`. . . . . . . . . . . . . . . . . . . . . . . 20
`
`20
`6 CGI Response
`. . . . . . . . . . . . . . . . . . . . . . . . 20
`.
`. . .
`.
`. . .
`. . .
`.
`.
`.
`.
`. .
`6.1 Response Handling .
`.
`. . . . . . . . . . . . . . . . . . . . . . . 20
`.
`. . .
`.
`. . .
`.
`. .
`.
`.
`.
`.
`6.2 Response Types . .
`. .
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 21
`6.2.1 Document Response . .
`6.2.2 Local Redirect Response . .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 21
`6.2.3 Client Redirect Response . .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 21
`6.2.4 Client Redirect Response with Document
`.
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 21
`6.3 Response Header Fields .
`.
`.
`.
`.
`. . .
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 22
`6.3.1 Content-Type .
`.
`.
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 22
`6.3.2 Location .
`. .
`.
`.
`.
`.
`.
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 23
`6.3.3
`Status .
`. .
`. . .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 23
`6.3.4
`Protocol-Specific Header Fields .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . 24
`6.3.5 Extension Header Fields . .
`. .
`. .
`. .
`. .
`. .
`. .
`. . . . . . . . . . . . . . . . . . . . . 24
`6.4 Response Message-Body .
`.
`.
`.
`. . .
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 24
`
`7 System Specifications
`. .
`7.1 AmigaDOS .
`.
`. .
`7.2 UNIX .
`.
`.
`.
`.
`7.3 EBCDIC/POSIX .
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`8 Implementation
`8.1 Recommendations for Servers
`8.2 Recommendations for Scripts .
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`
`. .
`. .
`. .
`
`.
`.
`.
`
`. . .
`. . .
`. . .
`
`.
`.
`.
`
`. . .
`. . .
`. . .
`
`.
`.
`.
`
`25
`. . . . . . . . . . . . . . . . . . . . . . . 25
`. . . . . . . . . . . . . . . . . . . . . . . 25
`. . . . . . . . . . . . . . . . . . . . . . . 25
`
`. .
`.
`. . .
`
`. . .
`.
`. . .
`.
`
`. . .
`.
`. . .
`.
`
`26
`. . . . . . . . . . . . . . . . . . . . . . . 26
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 26
`
`27
`9 Security Considerations
`. . . . . . . . . . . . . . . . . . . . . . 27
`. . .
`.
`. . .
`.
`. . .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`9.1 Safe Methods .
`. .
`. . .
`. . . . . . . . . . . . . . . . . . . . . . . 27
`9.2 Header Fields Containing Sensitive Information .
`9.3 Data Privacy . .
`. . .
`. .
`.
`.
`.
`.
`. . .
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 27
`9.4
`Information Security Model
`.
`.
`. . . .
`.
`. . .
`.
`. . .
`. . . . . . . . . . . . . . . . . . . . . . . 27
`9.5 Script Interference with the Server . . .
`.
`. . .
`.
`. . .
`. . . . . . . . . . . . . . . . . . . . . . . 28
`9.6 Data Length and Buffering Considerations . . .
`.
`. . .
`. . . . . . . . . . . . . . . . . . . . . . . 28
`9.7 Stateless Processing .
`.
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`. . .
`.
`. . .
`. . . . . . . . . . . . . . . . . . . . . . 28
`9.8 Relative Paths .
`. . .
`. .
`.
`.
`.
`.
`. . .
`. . .
`.
`. . .
`.
`. . . . . . . . . . . . . . . . . . . . . . . . 29
`9.9 Non-parsed Header Output
`.
`.
`.
`. . . .
`.
`. . .
`.
`. . .
`. . . . . . . . . . . . . . . . . . . . . . . 29
`
`10 Acknowledgements
`
`29
`
`11 References
`.
`11.1 Normative References .
`11.2 Informative References .
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`. .
`. .
`
`.
`.
`
`. . .
`. . .
`
`.
`.
`
`. . .
`. . .
`
`.
`.
`
`29
`. . . . . . . . . . . . . . . . . . . . . . . 29
`. . . . . . . . . . . . . . . . . . . . . . . 30
`
`12 Authors’ Addresses
`
`13 Full Copyright Statement
`
`Robinson & Coar
`
`Informational
`
`31
`
`32
`
`[Page 3]
`
`Google Ex. 1009, pg 3
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`1 Introduction
`
`1.1 Purpose
`
`The Common Gateway Interface (CGI) [22] allows an HTTP [1], [4] server and a CGI script to share responsibility
`for responding to client requests. The client request comprises a Uniform Resource Identifier (URI) [11], a request
`method and various ancillary information about the request provided by the transport protocol.
`
`The CGI defines the abstract parameters, known as meta-variables, which describe a client’s request. Together
`with a concrete programmer interface this specifies a platform-independent interface between the script and the
`HTTP server.
`
`The server is responsible for managing connection, data transfer, transport and network issues related to the client
`request, whereas the CGI script handles the application issues, such as data access and document processing.
`
`1.2 Requirements
`
`The key words ‘MUST’, ‘MUST NOT’, ‘REQUIRED’, ‘SHALL’, ‘SHALL NOT’, ‘SHOULD’, ‘SHOULD NOT’,
`‘RECOMMENDED’, ‘MAY’ and ‘OPTIONAL’ in this document are to be interpreted as described in BCP 14,
`RFC 2119 [3].
`
`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 all of the functions and features of the CGI are defined in the main part of this specification. The following
`phrases are used to describe the features that are not 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.
`
`Robinson & Coar
`
`Informational
`
`[Page 4]
`
`Google Ex. 1009, pg 4
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`1.4 Terminology
`
`This specification uses many terms defined in the HTTP/1.1 specification [4]; however, the following terms are
`used here in a sense which may not accord with their definitions in that document, or with their common meaning.
`
`‘meta-variable’
`A named parameter which carries information from the server to the script. It is not necessarily a variable
`in the operating system’s environment, although that is the most common implementation.
`
`‘script’
`The software that is invoked by the server according to this interface. It need not be a standalone program,
`but 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, as the term ‘script’ is frequently understood, but that is not a requirement
`and within the context of this specification the term has the broader definition stated.
`
`‘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
`
`All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur
`Form (BNF) similar to that used by RFC 822 [13]. Unless stated otherwise, the elements are case-sensitive. This
`augmented BNF contains the following constructs:
`
`name = definition
`The name of a rule and its definition are separated by the equals character (‘=’). Whitespace is only signifi-
`cant in that continuation lines of a definition are indented.
`
`“literal”
`Double quotation marks (") surround literal text, except for a literal quotation mark, which is surrounded by
`angle-brackets (‘<’ and ‘>’).
`
`rule1 | rule2
`Alternative rules are separated by a vertical bar (‘|’).
`
`(rule1 rule2 rule3)
`Elements enclosed in parentheses are treated as a single element.
`
`*rule
`
`A rule preceded by an asterisk (‘*’) may have zero or more occurrences. The full form is ‘n*m rule’
`indicating at least n and at most m occurrences of the rule. n and m are optional decimal values with default
`values of 0 and infinity respectively.
`
`Robinson & Coar
`
`Informational
`
`[Page 5]
`
`Google Ex. 1009, pg 5
`
`

`

`RFC 3875
`
`[rule]
`
`CGI Version 1.1
`
`October 2004
`
`An element enclosed in square brackets (‘[’ and ‘]’) is optional, and is equivalent to ‘*1 rule’.
`
`N rule
`A rule preceded by a decimal number represents exactly N occurrences of the rule. It is equivalent to ‘N*N
`rule’.
`
`2.2 Basic Rules
`
`This specification uses a BNF-like grammar defined in terms of characters. Unlike many specifications which
`define the bytes allowed by a protocol, here each literal in the grammar corresponds to the character it represents.
`How these characters are represented in terms of bits and bytes within a system are either system-defined or
`specified in the particular context. The single exception is the rule ‘OCTET’, defined below.
`
`The following rules are used throughout this specification to describe basic parsing constructs.
`
`alpha
`lowalpha
`
`hialpha
`
`= lowalpha | 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"
`= "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"
`= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
`"8" | "9"
`= alpha | digit
`= <any 8-bit byte>
`= alpha | digit | separator | "!" | "#" | "$" |
`"%" | "&" | "’" | "*" | "+" | "-" | "." | "`" |
`"ˆ" | "_" | "{" | "|" | "}" | "˜" | CTL
`= <any control character>
`= <space character>
`= <horizontal tab character>
`= <newline>
`= SP | HT | NL
`= "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
`"\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
`"}" | SP | HT
`= 1*<any CHAR except CTLs or separators>
`token
`quoted-string = <"> *qdtext <">
`qdtext
`= <any CHAR except <"> and CTLs but including LWSP>
`TEXT
`= <any printable character>
`
`digit
`
`alphanum
`OCTET
`CHAR
`
`CTL
`SP
`HT
`NL
`LWSP
`separator
`
`Robinson & Coar
`
`Informational
`
`[Page 6]
`
`Google Ex. 1009, pg 6
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`Note that newline (NL) need not be a single control character, but can be a sequence of control characters. A
`system MAY define TEXT to be a larger set of characters than <any CHAR excluding CTLs but including LWSP>.
`
`2.3 URL Encoding
`
`Some variables and constructs used here are described as being ‘URL-encoded’. This encoding is described
`in section 2 of RFC 2396 [2].
`In a URL-encoded string an escape sequence consists of a percent character
`(“%”) followed by two hexadecimal digits, where the two hexadecimal digits form an octet. An escape sequence
`represents the graphic character that has the octet as its code within the US-ASCII [9] coded character set, if it
`exists. Currently there is no provision within the URI syntax to identify which character set non-ASCII codes
`represent, so CGI handles this issue on an ad-hoc basis.
`
`Note that some unsafe (reserved) characters may have different semantics when encoded. The definition of which
`characters are unsafe depends on the context; see section 2 of RFC 2396 [2], updated by RFC 2732 [7], for
`an authoritative treatment. These reserved characters are generally used to provide syntactic structure to the
`character string, for example as field separators.
`In all cases, the string is first processed with regard to any
`reserved characters present, and then the resulting data can be URL-decoded by replacing “%” escape sequences
`by their character values.
`
`To encode a character string, all reserved and forbidden characters are replaced by the corresponding “%” escape
`sequences. The string can then be used in assembling a URI. The reserved characters will vary from context to
`context, but will always be drawn from this set:
`
`reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" |
`"," | "[" | "]"
`
`The last two characters were added by RFC 2732 [7]. In any particular context, a sub-set of these characters will
`be reserved; the other characters from this set MUST NOT be encoded when a string is URL-encoded in that
`context. Other basic rules used to describe URI syntax are:
`
`hex
`
`= digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" |
`"b" | "c" | "d" | "e" | "f"
`= "%" hex hex
`escaped
`unreserved = alpha | digit | mark
`mark
`= "-" | "_" | "." | "!" | "˜" | "*" | "’" | "(" | ")"
`
`3 Invoking the Script
`
`3.1 Server Responsibilities
`
`The server acts as an application gateway. It receives the request from the client, selects a CGI script to handle
`the request, converts the client request to a CGI request, executes the script and converts the CGI response into
`a response for the client. When processing the client request, it is responsible for implementing any protocol
`
`Robinson & Coar
`
`Informational
`
`[Page 7]
`
`Google Ex. 1009, pg 7
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`or transport level authentication and security. The server MAY also function in a ‘non-transparent’ manner,
`modifying the request or response in order to provide some additional service, such as media type transformation
`or protocol reduction.
`
`The server MUST perform translations and protocol conversions on the client request data required by this speci-
`fication. Furthermore, the server retains its responsibility to the client to conform to the relevant network protocol
`even if the CGI script fails to conform to this specification.
`
`If the server is applying authentication to the request, then it MUST NOT execute the script unless the request
`passes all defined access controls.
`
`3.2 Script Selection
`
`The server determines which CGI is script to be executed based on a generic-form URI supplied by the client.
`This URI includes a hierarchical path with components separated by “/”. For any particular request, the server
`will identify all or a leading part of this path with an individual script, thus placing the script at a particular point
`in the path hierarchy. The remainder of the path, if any, is a resource or sub-resource identifier to be interpreted
`by the script.
`
`Information about this split of the path is available to the script in the meta-variables, described below. Support
`for non-hierarchical URI schemes is outside the scope of this specification.
`
`3.3 The Script-URI
`
`The mapping from client request URI to choice of script is defined by the particular server implementation and its
`configuration. The server may allow the script to be identified with a set of several different URI path hierarchies,
`and therefore is permitted to replace the URI by other members of this set during processing and generation of 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 thus generated, a URI, the ‘Script-URI’, can be constructed. This MUST have the
`property that if the client had accessed this URI instead, then 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], with the exception that object parameters
`and fragment identifiers are not permitted. The various components 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>
`
`Robinson & Coar
`
`Informational
`
`[Page 8]
`
`Google Ex. 1009, pg 8
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`where <scheme> is found from SERVER_PROTOCOL, <server-name>, <server-port> and <query-string> are the
`values of the 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 information about the
`PATH_INFO meta-variable.
`
`The scheme and the protocol are not identical as the scheme identifies the access method in addition to 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 provides no generic means for
`the script to reconstruct this, and therefore the Script-URI as defined includes the base protocol used. However, a
`script MAY make use of scheme-specific meta-variables to better deduce the URI scheme.
`
`Note that this definition also allows URIs to be constructed which would invoke the script with any permitted
`values for the path-info or query-string, by modifying the appropriate components.
`
`3.4 Execution
`
`The script is invoked in a system-defined manner. Unless specified otherwise, the file containing the script will be
`invoked as an executable program. The server prepares the CGI request as described in section 4; this comprises
`the request meta-variables (immediately available to the script on execution) and request message data. The
`request data need not be immediately available to the script; the script can be executed before all this data has
`been received by the server from the client. The response from the script is returned to the server as described in
`sections 5 and 6.
`
`In the event of an error condition, the server can interrupt or terminate script execution at any time and without
`warning. That could occur, for example, in the event of a transport failure between the server and the client; so
`the script SHOULD be prepared to handle abnormal termination.
`
`4 The CGI Request
`
`Information about a request comes from two different sources; the request meta-variables and any associated
`message-body.
`
`4.1 Request Meta-Variables
`
`Meta-variables contain data about the request passed from the server to the script, and are accessed by the script in
`a system-defined manner. Meta-variables are identified by case-insensitive names; there cannot be two different
`variables whose names differ in case only. Here they are shown using a canonical representation of capitals plus
`underscore (“_”). A particular system can define a different representation.
`
`meta-variable-name = "AUTH_TYPE" | "CONTENT_LENGTH" |
`"CONTENT_TYPE" | "GATEWAY_INTERFACE" |
`"PATH_INFO" | "PATH_TRANSLATED" |
`
`Robinson & Coar
`
`Informational
`
`[Page 9]
`
`Google Ex. 1009, pg 9
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`"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 | scheme ) "_" var-name
`protocol-var-name
`= alpha *( alpha | digit | "+" | "-" | "." )
`scheme
`= token
`var-name
`extension-var-name = token
`
`Meta-variables with the same name as a scheme, and names beginning with the name of a protocol or scheme
`(e.g. HTTP_ACCEPT) are also defined. 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, whose names SHOULD be
`prefixed with “X_”.
`
`This specification does not distinguish between zero-length (NULL) values and missing values. For example, a
`script cannot distinguish between the two requests http://host/script and http://host/script?
`as in both cases the QUERY_STRING meta-variable would be NULL.
`
`meta-variable-value = "" | 1*<TEXT, CHAR or tokens of value>
`
`An optional meta-variable may be omitted (left unset) if its value is NULL. Meta-variable values MUST be
`considered case-sensitive except as noted otherwise. The representation of the characters in the meta-variables is
`system-defined; the server MUST convert values to that representation.
`
`4.1.1 AUTH_TYPE
`
`The AUTH_TYPE variable identifies any mechanism used by the server to authenticate the user. It contains a
`case-insensitive value defined by the client protocol or server implementation.
`
`For HTTP, if the client request required authentication for external access, then the server MUST set the value of
`this variable from the ‘auth-scheme’ token in the request Authorization header field.
`
`= "" | auth-scheme
`AUTH_TYPE
`= "Basic" | "Digest" | extension-auth
`auth-scheme
`extension-auth = token
`
`HTTP access authentication schemes are described in RFC 2617 [5].
`
`Robinson & Coar
`
`Informational
`
`[Page 10]
`
`Google Ex. 1009, pg 10
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`4.1.2 CONTENT_LENGTH
`
`The CONTENT_LENGTH variable contains the size of the message-body attached to the request, if any, in
`decimal number of octets. If no data is attached, then NULL (or unset).
`
`CONTENT_LENGTH = "" | 1*digit
`
`The server MUST set this meta-variable if and only if the request is accompanied by 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, the CONTENT_TYPE variable is set to the Internet Media Type [6] of
`the 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 are not case-sensitive. Parameter values may be case sensitive.
`Media types and their use in HTTP are described section 3.7 of the HTTP/1.1 specification [4].
`
`There is no default value for this variable. If and only if it is unset, then the script MAY attempt to determine the
`media type from the data received. If the type remains unknown, then the script MAY choose to assume a type of
`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 may include a charset parameter with a
`case-insensitive value defining the coded character set for the message-body. If the charset parameter is omitted,
`then the default value should be derived according to whichever of the following rules is the first to apply:
`
`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 receives a request with an attached entity but no Content-Type header field, it MAY attempt to determine
`the correct content type, otherwise it should omit this meta-variable.
`
`Robinson & Coar
`
`Informational
`
`[Page 11]
`
`Google Ex. 1009, pg 11
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`4.1.4 GATEWAY_INTERFACE
`
`The GATEWAY_INTERFACE variable MUST be set to the dialect of CGI being used by the server to communi-
`cate with the script. Syntax:
`
`GATEWAY_INTERFACE = "CGI" "/" 1*digit "." 1*digit
`
`Note that the major and minor numbers are treated as separate integers and hence each may be incremented higher
`than a single digit. Thus 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
`
`The PATH_INFO variable specifies a path to be interpreted by the CGI script. It identifies the resource or sub-
`resource to be returned by the CGI script, and is derived from the portion of the URI path hierarchy following the
`part that identifies the script itself. Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot 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 considered case-sensitive and the server MUST preserve the case of the path as presented in the
`request URI. The server MAY impose restrictions and limitations on what values it permits for PATH_INFO, and
`MAY reject the request with an error if it encounters any values considered objectionable. That MAY include any
`requests that would result in an encoded “/” being decoded into PATH_INFO, as this might represent a loss of
`information to the script. Similarly, treatment of non US-ASCII characters in the path is system-defined.
`
`URL-encoded, the PATH_INFO string forms the extra-path component of the Script-URI (see section 3.3) which
`follows the SCRIPT_NAME part of that path.
`
`4.1.6 PATH_TRANSLATED
`
`The PATH_TRANSLATED variable is derived by taking the PATH_INFO value, parsing it as a local URI in its
`own right, and performing any virtual-to-physical translation appropriate to map it onto the server’s document
`repository structure. The set of characters permitted 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>
`
`Robinson & Coar
`
`Informational
`
`[Page 12]
`
`Google Ex. 1009, pg 12
`
`

`

`RFC 3875
`
`CGI Version 1.1
`
`October 2004
`
`where <scheme> is the scheme for the original client request and <extra-path> is a URL-encoded version of
`PATH_INFO, with “;”, “=” and “?” reserved. For example, a request such as the following:
`
`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 constructed from the scheme, server location and the URL-encoded PATH_INFO:
`
`http://somehost.com/this.is.the.path%3binfo
`
`This would then be translated to a location in the server’s document repository, perhaps a filesystem path some-
`thing like this:
`
`/usr/local/www/htdocs/this.is.the.path;info
`
`The value of PATH_TRANSLATED is the result of the translation.
`
`The value is derived in this way irrespective of whether 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 preserve the case of the original segment through the translation.
`
`The translation algorithm the server uses to derive PATH_TRANSLATED is implementation-defined; CGI scripts
`which use this variable may suffer limited portability.
`
`The server SHOULD set this meta-variable if the request URI includes a path-info component. If PATH_INFO is
`NULL, then the PATH_TRANSLATED variable MUST be set to NULL (or unset).
`
`4.1.7 QUERY_STRING
`
`The QUERY_STRING variable contains a URL-encoded search or parameter string; it provides information to
`the CGI script to affect or refine the document to be returned by the script.
`
`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 a