Network Working Group D. Robinson
Request for Comments: 3875 K. Coar
Category: Informational The Apache Software Foundation
October 2004
Network Working Group D. Robinson
Request for Comments: 3875 K. Coar
Category: Informational The Apache Software Foundation
October 2004
The Common Gateway Interface (CGI) Version 1.1
通用网关接口（CGI）版本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).
版权所有（C）互联网协会（2004年）。
IESG Note
IESG注释
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.
本文件不适用于任何级别的互联网标准。IETF不承认对本文件适用于任何目的的任何了解，特别注意到IETF没有对安全性、拥塞控制或与已部署协议的不当交互等事项进行审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。
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.
公共网关接口（CGI）是一个简单的接口，用于以独立于平台的方式在信息服务器下运行外部程序、软件或网关。目前，支持的信息服务器是HTTP服务器。
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 Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems.
该界面自1993年以来一直被万维网（WWW）使用。本规范定义了在美国国家超级计算应用中心开发和记录的“CGI/1.1”接口的“当前实践”参数。本文档还定义了在UNIX（R）和其他类似系统上使用CGI/1.1接口。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specifications . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 5
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
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
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
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
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
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
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
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
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
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 33
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References. . . . . . . . . . . . . . . . . . 33
11.2. Informative References. . . . . . . . . . . . . . . . . 34
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References. . . . . . . . . . . . . . . . . . 33
11.2. Informative References. . . . . . . . . . . . . . . . . 34
12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 35
12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 35
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 36
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 36
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.
公共网关接口（CGI）[22]允许HTTP[1]、[4]服务器和CGI脚本分担响应客户端请求的责任。客户端请求包括统一资源标识符（URI）[11]、请求方法和由传输协议提供的关于请求的各种辅助信息。
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.
CGI定义了抽象参数，称为元变量，用于描述客户机的请求。与一个具体的程序员接口一起，它指定了脚本和HTTP服务器之间的一个独立于平台的接口。
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.
服务器负责管理与客户端请求相关的连接、数据传输、传输和网络问题，而CGI脚本处理应用程序问题，如数据访问和文档处理。
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].
本文件中的关键词‘必须’、‘不得’、‘必需’、‘应’、‘不应该’、‘建议’、‘可能’和‘可选’应按照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'.
如果一个实现未能满足其实现的协议的一个或多个“必须”要求，则该实现是不兼容的。满足其特性的所有“必须”和所有“应该”要求的实现称为“无条件兼容”；一个满足所有“必须”要求但并非所有“应该”要求的特性被称为“有条件兼容”。
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:
本规范的主要部分并未定义CGI的所有功能和特性。以下短语用于描述未指定的功能：
'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.
“系统定义”不同系统之间的功能可能不同，但对于使用同一系统的不同实现，功能必须相同。系统通常会识别一类操作系统。本文件第7节定义了一些系统。新系统可由新规范定义，无需修订本文件。
'implementation-defined' The behaviour of the feature may vary from implementation to implementation; a particular implementation must document its behaviour.
“实施定义”功能的行为可能因实施而异；特定的实现必须记录其行为。
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.
本规范使用了HTTP/1.1规范[4]中定义的许多术语；然而，此处使用的下列术语可能与该文件中的定义或其共同含义不一致。
'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.
“服务器”调用脚本以服务客户端请求的应用程序。
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:
本文件中规定的所有机制均以散文和类似于RFC 822[13]所用的增广巴科斯-诺尔形式（BNF）进行了描述。除非另有说明，否则元素区分大小写。此扩充BNF包含以下结构：
name = definition The name of a rule and its definition are separated by the equals character ('='). Whitespace is only significant 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 ('|').
规则1 |规则2备选规则由竖条（“|”）分隔。
(rule1 rule2 rule3) Elements enclosed in parentheses are treated as a single element.
（规则1规则2规则3）括号内的元素被视为单个元素。
*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.
*规则前面带有星号（“*”）的规则可能不出现或出现多次。完整表单为“n*m规则”，表示该规则至少出现n次，最多出现m次。n和m是可选的十进制值，默认值分别为0和无穷大。
[rule] An element enclosed in square brackets ('[' and ']') is optional, and is equivalent to '*1 rule'.
[规则]方括号（“[”和“]”）中的元素是可选的，相当于“*1规则”。
N rule A rule preceded by a decimal number represents exactly N occurrences of the rule. It is equivalent to 'N*N rule'.
N规则前面有一个十进制数的规则正好代表该规则的N次出现。它相当于“N*N规则”。
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.
本规范使用以字符为单位定义的类似BNF的语法。与定义协议允许的字节的许多规范不同，这里语法中的每个文本对应于它所表示的字符。这些字符在系统中以位和字节表示的方式由系统定义或在特定上下文中指定。唯一的例外是规则“八位字节”，定义如下。
The following rules are used throughout this specification to describe basic parsing constructs.
本规范中使用以下规则来描述基本的解析构造。
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"
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>
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>
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>.
请注意，换行符（NL）不需要是单个控制字符，但可以是控制字符序列。系统可以将文本定义为比<任何字符（不包括CTL，但包括LWSP>）更大的字符集。
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.
这里使用的一些变量和结构被描述为“URL编码”。RFC 2396[2]第2节描述了这种编码。在URL编码的字符串中，转义序列由百分比字符（“%”）和两个十六进制数字组成，其中两个十六进制数字构成八位字节。转义序列表示在US-ASCII[9]编码字符集中以八位字节作为其代码的图形字符（如果存在）。目前，URI语法中没有规定识别非ASCII代码代表的字符集，因此CGI在特殊的基础上处理这个问题。
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.
请注意，某些不安全（保留）字符在编码时可能具有不同的语义。哪些字符不安全的定义取决于上下文；参见RFC 2396[2]第2节，由RFC 2732[7]更新，以获得权威性处理。这些保留字符通常用于为字符串提供语法结构，例如作为字段分隔符。在所有情况下，首先针对存在的任何保留字符处理字符串，然后通过将“%”转义序列替换为其字符值来对结果数据进行URL解码。
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:
要对字符串进行编码，所有保留字符和禁止字符都将替换为相应的“%”转义序列。然后可以在组装URI时使用该字符串。保留字符因上下文而异，但始终从此集合中提取：
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" |
"," | "[" | "]"
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:
最后两个字符由RFC 2732[7]添加。在任何特定上下文中，将保留这些字符的子集；在该上下文中对字符串进行URL编码时，不得对该集中的其他字符进行编码。用于描述URI语法的其他基本规则包括：
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b"
| "c" | "d" | "e" | "f"
escaped = "%" hex hex
unreserved = alpha | digit | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b"
| "c" | "d" | "e" | "f"
escaped = "%" hex hex
unreserved = alpha | digit | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
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 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.
服务器充当应用程序网关。它从客户端接收请求，选择CGI脚本来处理请求，将客户端请求转换为CGI请求，执行脚本并将CGI响应转换为客户端的响应。在处理客户端请求时，它负责实现任何协议或传输级别的身份验证和安全性。服务器也可能以“不透明”的方式运行，修改请求或响应以提供一些附加服务，例如媒体类型转换或协议缩减。
The server MUST perform translations and protocol conversions on the client request data required by this specification. 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.
服务器必须对本规范要求的客户端请求数据执行翻译和协议转换。此外，即使CGI脚本不符合此规范，服务器仍保留其对客户端遵守相关网络协议的责任。
If the server is applying authentication to the request, then it MUST NOT execute the script unless the request passes all defined access controls.
如果服务器正在对请求应用身份验证，则除非请求通过了所有定义的访问控制，否则它不得执行脚本。
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.
服务器根据客户端提供的通用表单URI确定要执行的CGI脚本。此URI包括一个分层路径，其中的组件由“/”分隔。对于任何特定请求，服务器将使用单个脚本标识此路径的所有或主要部分，从而将脚本放置在路径层次结构中的特定点上。路径的其余部分（如果有）是要由脚本解释的资源或子资源标识符。
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.
有关此路径拆分的信息可在元变量中找到，如下所述。对非分层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
从客户端请求URI到脚本选择的映射由特定的服务器实现及其配置定义。服务器可以允许用一组几个不同的URI路径层次结构来标识脚本，因此允许在元变量的处理和生成期间用该组的其他成员替换URI。服务器
1. MAY preserve the URI in the particular client request; or
1. 可以在特定客户端请求中保留URI；或
2. it MAY select a canonical URI from the set of possible values for each script; or
2. 它可以从每个脚本的一组可能值中选择一个规范URI；或
3. it can implement any other selection of URI from the set.
3. 它可以实现从集合中选择的任何其他URI。
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);
根据由此生成的元变量，可以构造URI，即“脚本URI”。这必须具有这样的属性：如果客户端访问了此URI，那么脚本将使用与脚本名称、路径信息和查询字符串元变量相同的值执行。脚本URI具有RFC 2396[2]第3节中定义的通用URI的结构，但不允许使用对象参数和片段标识符。脚本URI的各个组件由一些元变量定义（见下文）；
script-URI = <scheme> "://" <server-name> ":" <server-port>
<script-path> <extra-path> "?" <query-string>
script-URI = <scheme> "://" <server-name> ":" <server-port>
<script-path> <extra-path> "?" <query-string>
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>.
其中，<scheme>是从SERVER_协议中找到的，<SERVER name>、<SERVER port>和<query string>是相应元变量的值。脚本名称和路径信息值，URL编码为“；”、“=”和“？”保留，给出<SCRIPT PATH>和<extra PATH>。
See section 4.1.5 for more information about the PATH_INFO meta-variable.
有关PATH_INFO元变量的更多信息，请参见第4.1.5节。
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.
方案和协议不完全相同，因为除了应用协议之外，方案还标识访问方法。例如，使用传输层安全性（TLS）[14]访问的资源在使用HTTP协议[19]时将具有https方案的请求URI。CGI/1.1没有为脚本提供重建该协议的通用方法，因此定义的脚本URI包括使用的基本协议。然而，脚本可以使用特定于方案的元变量来更好地推断URI方案。
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.
请注意，此定义还允许构造URI，通过修改适当的组件，URI将使用路径信息或查询字符串的任何允许值调用脚本。
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.
脚本是以系统定义的方式调用的。除非另有规定，否则包含脚本的文件将作为可执行程序调用。服务器按照第4节所述准备CGI请求；这包括请求元变量（执行时脚本立即可用）和请求消息数据。请求数据不需要立即可用于脚本；在服务器从客户端接收到所有这些数据之前，可以执行脚本。脚本的响应将返回到服务器，如第5节和第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.
在出现错误情况时，服务器可以随时中断或终止脚本执行，而无需发出警告。例如，在服务器和客户端之间发生传输故障时，可能会发生这种情况；所以脚本应该准备好处理异常终止。
Information about a request comes from two different sources; the request meta-variables and any associated message-body.
关于请求的信息来自两个不同的来源；请求元变量和任何关联的消息体。
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.
元变量包含有关从服务器传递到脚本的请求的数据，脚本以系统定义的方式访问元变量。元变量由不区分大小写的名称标识；不能有两个名称仅大小写不同的变量。在这里，它们使用大写字母加下划线（“\ux”）的规范表示法显示。特定系统可以定义不同的表示形式。
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-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 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.)
还定义了与方案名称相同的元变量，以及以协议或方案名称开头的名称（例如HTTP_ACCEPT）。这些变量的数量和含义可能独立于本规范而变化。（另见第4.1.18节。）
The server MAY set additional implementation-defined extension meta-variables, whose names SHOULD be prefixed with "X_".
服务器可以设置附加的实现定义的扩展元变量，其名称应以“X_3;”作为前缀。
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.
本规范不区分零长度（NULL）值和缺失值。例如，脚本无法区分这两个请求http://host/script 和http://host/script? 在这两种情况下，查询字符串元变量都将为NULL。
meta-variable-value = "" | 1*<TEXT, CHAR or tokens of value>
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.
如果可选元变量的值为空，则可以省略它（未设置）。元变量值必须视为区分大小写，除非另有说明。元变量中字符的表示是系统定义的；服务器必须将值转换为该表示形式。
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.
AUTH_TYPE变量标识服务器用于对用户进行身份验证的任何机制。它包含由客户端协议或服务器实现定义的不区分大小写的值。
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.
对于HTTP，如果客户端请求需要外部访问的身份验证，则服务器必须从请求授权标头字段中的“auth scheme”标记设置此变量的值。
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | extension-auth
extension-auth = token
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | extension-auth
extension-auth = token
HTTP access authentication schemes are described in RFC 2617 [5].
RFC 2617[5]中描述了HTTP访问身份验证方案。
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变量包含附加到请求的消息体的大小（如果有），以十进制的八位字节数表示。如果未附加任何数据，则为NULL（或unset）。
CONTENT_LENGTH = "" | 1*digit
CONTENT_LENGTH=”“| 1*位
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.
当且仅当请求附有消息体实体时，服务器必须设置此元变量。CONTENT_LENGTH值必须反映服务器删除任何传输编码或内容编码后邮件正文的长度。
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变量设置为消息正文的Internet媒体类型[6]。
CONTENT_TYPE = "" | media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
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].
类型、子类型和参数属性名称不区分大小写。参数值可能区分大小写。HTTP/1.1规范[4]第3.7节描述了媒体类型及其在HTTP中的使用。
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).
此变量没有默认值。如果且仅当未设置时，脚本可尝试根据接收到的数据确定媒体类型。如果类型仍然未知，则脚本可以选择假定应用程序/八位字节流的类型，或者可能会拒绝请求并出现错误（如第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:
如果省略charset参数，则应根据以下规则中最先应用的规则导出默认值：
1. There MAY be a system-defined default charset for some media-types.
1. 某些媒体类型可能有系统定义的默认字符集。
2. The default for media-types of type "text" is ISO-8859-1 [4].
2. “文本”类型的媒体类型的默认值为ISO-8859-1[4]。
3. Any default defined in the media-type specification.
3. 介质类型规范中定义的任何默认值。
4. The default is US-ASCII.
4. 默认值为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.
如果客户端请求标头中存在HTTP内容类型字段，则服务器必须设置此元变量。如果服务器接收到带有附加实体但没有内容类型头字段的请求，它可能会尝试确定正确的内容类型，否则它应该忽略此元变量。
The GATEWAY_INTERFACE variable MUST be set to the dialect of CGI being used by the server to communicate with the script. Syntax:
GATEWAY_接口变量必须设置为服务器用于与脚本通信的CGI方言。语法：
GATEWAY_INTERFACE = "CGI" "/" 1*digit "." 1*digit
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.
请注意，主要数字和次要数字被视为单独的整数，因此每个数字的增量可能高于一个位数。因此，CGI/2.4的版本低于CGI/2.13，而CGI/2.13又低于CGI/12.3。前导零必须被脚本忽略，并且不能由服务器生成。
This document defines the 1.1 version of the CGI interface.
本文档定义了CGI接口的1.1版本。
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变量指定CGI脚本要解释的路径。它标识CGI脚本要返回的资源或子资源，并派生自URI路径层次结构中标识脚本本身的部分之后的部分。与URI路径不同，路径信息不是URL编码的，并且不能包含路径段参数。路径信息“/”表示单个空路径段。
PATH_INFO = "" | ( "/" path )
path = lsegment *( "/" lsegment )
lsegment = *lchar
lchar = <any TEXT or CTL except "/">
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.
该值视为区分大小写，服务器必须保留请求URI中显示的路径大小写。服务器可能会对其允许的PATH_INFO值施加限制和限制，如果遇到任何被认为不合适的值，则可能会以错误拒绝请求。这可能包括将导致编码“/”解码为路径_INFO的任何请求，因为这可能表示脚本丢失信息。同样，路径中非US-ASCII字符的处理由系统定义。
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.
URL编码，路径信息字符串形成脚本URI的额外路径组件（参见第3.3节），该组件位于该路径的脚本名称部分之后。
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变量是通过获取PATH_INFO值，将其本身解析为本地URI，并执行任何适合于将其映射到服务器文档存储库结构的虚拟到物理转换来派生的。结果中允许的字符集是系统定义的。
PATH_TRANSLATED = *<any character>
PATH_TRANSLATED = *<any character>
This is the file location that would be accessed by a request for
这是请求访问的文件位置
<scheme> "://" <server-name> ":" <server-port> <extra-path>
<scheme> "://" <server-name> ":" <server-port> <extra-path>
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:
其中，<scheme>是原始客户端请求的方案，<extra path>是路径信息的URL编码版本，保留“；”、“=”和“？”。例如，请求如下所示：
http://somehost.com/cgi-bin/somescript/this%2eis%2epath%3binfo
http://somehost.com/cgi-bin/somescript/this%2eis%2epath%3binfo
would result in a PATH_INFO value of
将导致路径_INFO值为
/this.is.the.path;info
/这是路径；信息
An internal URI is constructed from the scheme, server location and the URL-encoded PATH_INFO:
内部URI由方案、服务器位置和URL编码路径_信息构成：
http://somehost.com/this.is.the.path%3binfo
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 something like this:
然后将其转换为服务器文档存储库中的一个位置，可能是一个文件系统路径，如下所示：
/usr/local/www/htdocs/this.is.the.path;info
/usr/local/www/htdocs/this.is.the.path;info
The value of PATH_TRANSLATED is the result of the translation.
路径_TRANSLATED的值是转换的结果。
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.
服务器用于导出路径_转换的转换算法由实现定义；使用此变量的CGI脚本的可移植性可能会受到限制。
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).
如果请求URI包含路径信息组件，则服务器应设置此元变量。如果PATH_INFO为NULL，则PATH_TRANSLATED变量必须设置为NULL（或unset）。
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.
QUERY_STRING变量包含URL编码的搜索或参数字符串；它向CGI脚本提供信息，以影响或优化脚本返回的文档。
The URL syntax for a search string is described in section 3 of RFC 2396 [2]. The QUERY_STRING value is case-sensitive.
RFC 2396[2]第3节描述了搜索字符串的URL语法。查询字符串值区分大小写。
QUERY_STRING = query-string
query-string = *uric
uric = reserved | unreserved | escaped
QUERY_STRING = query-string
query-string = *uric
uric = reserved | unreserved | escaped
When parsing and decoding the query string, the details of the parsing, reserved characters and support for non US-ASCII characters depends on the context. For example, form submission from an HTML document [18] uses application/x-www-form-urlencoded encoding, in which the characters "+", "&" and "=" are reserved, and the ISO 8859-1 encoding may be used for non US-ASCII characters.
解析和解码查询字符串时，解析的详细信息、保留字符和对非US-ASCII字符的支持取决于上下文。例如，来自HTML文档[18]的表单提交使用application/x-www-form-urlencoded编码，其中保留字符“+”、“&”和“=”，ISO 8859-1编码可用于非US-ASCII字符。
The QUERY_STRING value provides the query-string part of the Script-URI. (See section 3.3).
QUERY_STRING值提供脚本URI的查询字符串部分。（见第3.3节）。
The server MUST set this variable; if the Script-URI does not include a query component, the QUERY_STRING MUST be defined as an empty string ("").
服务器必须设置此变量；如果脚本URI不包含查询组件，则必须将查询字符串定义为空字符串（“”）。
The REMOTE_ADDR variable MUST be set to the network address of the client sending the request to the server.
REMOTE_ADDR变量必须设置为向服务器发送请求的客户端的网络地址。
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 )
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].
RFC 3513[15]中描述了IPv6地址的格式。
The REMOTE_HOST variable contains the fully qualified domain name of the client sending the request to the server, if available, otherwise NULL. Fully qualified domain names take the form as 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变量包含向服务器发送请求的客户端的完全限定域名（如果可用），否则为NULL。完全限定域名采用RFC 1034[17]第3.5节和RFC 1123[12]第2.1节所述的形式。域名不区分大小写。
REMOTE_HOST = "" | hostname | hostnumber
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum [ *alphahypdigit alphanum ]
toplabel = alpha [ *alphahypdigit alphanum ]
alphahypdigit = alphanum | "-"
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 is not available for performance reasons or otherwise, the server MAY substitute the REMOTE_ADDR value.
服务器应设置此变量。如果主机名因性能原因或其他原因不可用，服务器可能会替换REMOTE_ADDR值。
The REMOTE_IDENT variable MAY be used to provide identity information reported about the connection by an RFC 1413 [20] request to the remote agent, if 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变量可用于向远程代理提供RFC 1413[20]请求报告的关于连接的标识信息（如果可用）。服务器可以选择不支持此功能，或者出于效率原因不请求数据，或者不返回可用的标识数据。
REMOTE_IDENT = *TEXT
REMOTE_IDENT = *TEXT
The data returned may be used for authentication purposes, but the level of trust reposed in it should be minimal.
返回的数据可以用于身份验证目的，但其中的信任级别应该是最低的。
The REMOTE_USER variable provides a user identification string supplied by client as part of user authentication.
REMOTE_USER变量提供客户端提供的用户标识字符串，作为用户身份验证的一部分。
REMOTE_USER = *TEXT
REMOTE_USER = *TEXT
If the client request required HTTP Authentication [5] (e.g., 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.
如果客户端请求需要HTTP身份验证[5]（例如，AUTH_类型元变量设置为“基本”或“摘要”），则远程_用户元变量的值必须设置为提供的用户ID。
The REQUEST_METHOD meta-variable MUST be set to the method which should be used by the script to process the request, as described in section 4.3.
REQUEST_METHOD元变量必须设置为脚本应用于处理请求的方法，如第4.3节所述。
REQUEST_METHOD = method
method = "GET" | "POST" | "HEAD" | extension-method
extension-method = "PUT" | "DELETE" | token
REQUEST_METHOD = method
method = "GET" | "POST" | "HEAD" | extension-method
extension-method = "PUT" | "DELETE" | token
The method is case sensitive. 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].
该方法区分大小写。HTTP方法在HTTP/1.0规范[1]的第5.1.1节和HTTP/1.1规范[4]的第5.1.1节中进行了描述。
The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded) which 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变量必须设置为URI路径（不是URL编码的），该路径可以标识CGI脚本（而不是脚本的输出）。语法与路径信息相同（第4.1.5节）
SCRIPT_NAME = "" | ( "/" path )
脚本_NAME=”“|（“/”路径）
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.
前导“/”不是路径的一部分。如果路径为空，则为可选；但是，在这种情况下仍然必须设置变量。
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.
SCRIPT_NAME字符串构成了脚本URI路径组件的某些前导部分，该脚本URI是以某种实现定义的方式派生的。脚本名称值中不包含路径信息段（见第4.1.5节）。
The SERVER_NAME variable MUST be set to the name of the server host to which the client request is directed. It is a case-insensitive hostname or network address. It forms the host part of the Script-URI.
SERVER_NAME变量必须设置为客户端请求指向的服务器主机的名称。它是不区分大小写的主机名或网络地址。它构成脚本URI的主机部分。
SERVER_NAME = server-name server-name = hostname | ipv4-address | ( "[" ipv6-address "]" )
服务器名称=服务器名称服务器名称=主机名| ipv4地址|（“[“ipv6地址”]”）
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.
已部署的服务器可以有多个此变量的可能值，其中多个HTTP虚拟主机共享同一IP地址。在这种情况下，服务器将使用请求的主机头字段的内容来选择正确的虚拟主机。
The SERVER_PORT variable MUST be set to the TCP/IP port number on which this request is received from the client. This value is used in the port part of the Script-URI.
服务器端口变量必须设置为从客户端接收此请求的TCP/IP端口号。此值用于脚本URI的端口部分。
SERVER_PORT = server-port server-port = 1*digit
服务器端口=服务器端口服务器端口=1*位
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.
请注意，必须设置此变量，即使端口是方案的默认端口，也可以从URI中省略。
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 used by the server in its communication with the client.
SERVER_PROTOCOL变量必须设置为用于此CGI请求的应用程序协议的名称和版本。这可能不同于服务器在与客户端通信时使用的协议版本。
SERVER_PROTOCOL = HTTP-Version | "INCLUDED" | extension-version
HTTP-Version = "HTTP" "/" 1*digit "." 1*digit
extension-version = protocol [ "/" 1*digit "." 1*digit ]
protocol = token
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 presented in upper case. The protocol is not the same as the scheme part of the script URI, which defines the overall access mechanism used by the client to communicate with the server. For example, a request that reaches the script with a protocol of "HTTP" may have used an "https" scheme.
这里，“协议”定义了服务器和脚本之间传递的一些信息的语法（“协议特定”功能）。它不区分大小写，通常用大写字母表示。该协议与脚本URI的scheme部分不同，后者定义了客户端用于与服务器通信的总体访问机制。例如，使用“HTTP”协议到达脚本的请求可能使用了“https”方案。
A well-known value for SERVER_PROTOCOL which 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.
服务器可能使用的服务器_协议的一个众所周知的值是“include”，它表示当前文档正在作为复合文档的一部分包括，而不是作为客户端请求的直接目标。脚本应将其视为HTTP/1.0请求。
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 any.
SERVER_软件元变量必须设置为发出CGI请求（并运行网关）的信息服务器软件的名称和版本。它应该与报告给客户端的服务器描述相同（如果有）。
SERVER_SOFTWARE = 1*( product | comment )
product = token [ "/" product-version ]
product-version = token
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
SERVER_SOFTWARE = 1*( product | comment )
product = token [ "/" product-version ]
product-version = token
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
The server SHOULD set meta-variables specific to the protocol and scheme for the request. Interpretation of 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 indicates to a script which scheme is used by the request.
服务器应该为请求设置特定于协议和方案的元变量。协议特定变量的解释取决于服务器协议中的协议版本。如果方案与协议不同，服务器可以将方案名称的元变量设置为非空值。此类变量的存在向脚本指示请求使用的方案。
Meta-variables with names beginning 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 can be rewritten in ways which 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.
如果所使用的协议是HTTP，则名称以“HTTP_”开头的元变量包含从客户端请求头字段读取的值。HTTP头字段名转换为大写，所有出现的“-”替换为“\u1”，并在前面加上“HTTP\u1”以给出元变量名。头数据可以表示为客户端发送的数据，也可以以不改变其语义的方式重写。如果收到具有相同字段名的多个标头字段，则服务器必须将其重写为具有相同语义的单个值。类似地，跨越多行的标题字段必须合并到一行中。如有必要，服务器必须更改数据的表示形式（例如，字符集）以适合CGI元变量。
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'.
服务器不需要为其接收的所有头字段创建元变量。特别是，它应该删除任何包含身份验证信息的头字段，例如“授权”；或者脚本在其他变量中可用，例如“内容长度”和“内容类型”。服务器可以删除仅与客户端通信问题相关的头字段，例如“连接”。
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
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.
如果内容长度不为NULL，则请求正文将随请求一起提供。服务器必须使脚本至少有足够多的字节可供读取。读取内容长度字节后，服务器可能会发出文件结束状态的信号，也可能会提供扩展数据。因此，即使有更多数据可用，脚本也不能尝试读取超过内容长度的字节。但是，它没有义务读取任何数据。
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.
对于非解析头（NPH）脚本（第5节），服务器应尝试确保提供给脚本的数据与客户端提供的数据完全相同，并且服务器不会更改。
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.
由于请求正文不支持传输编码，服务器必须从消息正文中删除任何此类编码，并重新计算内容长度。如果这是不可能的（例如，由于大的缓冲要求），服务器应该拒绝客户机请求。它还可以从消息正文中删除内容编码。
The Request Method, as supplied in the REQUEST_METHOD meta-variable, identifies the processing method to be applied by the script in producing a response. The script author can choose to implement the methods 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).
Request_Method元变量中提供的Request方法标识脚本在生成响应时要应用的处理方法。脚本作者可以选择实现最适合特定应用程序的方法。如果脚本接收到不支持的方法请求，则应拒绝该请求并出错（见第6.3.3节）。
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 SHOULD NOT have the significance of taking an action other than producing a document.
GET方法指示脚本应该基于元变量值生成文档。按照惯例，GET方法是“安全的”和“幂等的”，并且除了生成文档之外，不应该具有执行操作的意义。
The meaning of the GET method may be modified and refined by protocol-specific meta-variables.
GET方法的含义可以通过协议特定的元变量进行修改和细化。
The POST method is used to request 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.
POST方法用于请求脚本执行处理，并根据请求消息体中的数据以及元变量值生成文档。一个常见的用途是HTML中的表单提交[18]，旨在通过脚本启动具有永久影响的处理，例如数据库中的更改。
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.
脚本在读取附加的消息正文之前必须检查CONTENT_LENGTH变量的值，并且在处理它之前应该检查CONTENT_TYPE值。
The HEAD method requests the script to 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.
HEAD方法请求脚本执行足够的处理以返回响应头字段，而不提供响应消息正文。脚本不得为HEAD请求提供响应消息正文。如果确实如此，则服务器在从脚本读取响应时必须丢弃消息体。
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.
该脚本可以实现任何特定于协议的方法，例如HTTP/1.1 PUT和DELETE；执行此操作时，它应该检查服务器_协议的值。
The server MAY decide that some methods are not appropriate or permitted for a script, and may handle the methods itself or return an error to the client.
服务器可能会决定某些方法不适合或不允许用于脚本，并且可能会自行处理这些方法或向客户端返回错误。
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
一些系统支持向CGI脚本提供字符串数组的方法。这仅用于“索引”HTTP查询的情况，该查询由“GET”或“HEAD”请求标识，URI查询字符串不包含任何未编码的“=”字符。对于此类请求，服务器应将查询字符串视为搜索字符串，并使用规则将其解析为单词
search-string = search-word *( "+" search-word )
search-word = 1*schar
schar = unreserved | escaped | xreserved
xreserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "," |
"$"
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.
解析后，每个搜索词都会进行URL解码，可以选择以系统定义的方式进行编码，然后添加到命令行参数列表中。
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 script SHOULD check to see if the QUERY_STRING value contains an unencoded "=" character, and SHOULD NOT use the command line arguments if it does.
脚本应检查查询字符串值是否包含未编码的“=”字符，如果包含，则不应使用命令行参数。
The server MAY support NPH (Non-Parsed Header) scripts; these are scripts to which the server passes all responsibility for response processing.
服务器可能支持NPH（非解析头）脚本；这些是服务器将响应处理的所有责任传递给的脚本。
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.
本规范不提供仅基于输出数据识别NPH脚本的机制。因此，按照惯例，任何特定脚本只能提供一种类型的输出（NPH或CGI），因此脚本本身被描述为“NPH脚本”。具有NPH支持的服务器必须提供实现定义的机制来识别NPH脚本，可能基于脚本的名称或位置。
There MUST be a system-defined method for the script to send data back to the server or client; a script MUST always return some data. Unless defined otherwise, this will be the same as for conventional CGI scripts.
脚本必须有系统定义的方法才能将数据发送回服务器或客户端；脚本必须始终返回一些数据。除非另有定义，否则这将与传统CGI脚本相同。
Currently, NPH scripts are only defined for HTTP client requests. An (HTTP) NPH script MUST return a complete HTTP response message, currently described in section 6 of the HTTP specifications [1], [4]. The script MUST use the SERVER_PROTOCOL variable to determine the appropriate format for a response. It MUST also take account of any generic or protocol-specific meta-variables in the request as might be mandated by the particular protocol specification.
目前，NPH脚本仅为HTTP客户端请求定义。（HTTP）NPH脚本必须返回完整的HTTP响应消息，目前在HTTP规范[1]、[4]的第6节中进行了描述。脚本必须使用SERVER_协议变量来确定响应的适当格式。它还必须考虑请求中的任何通用或协议特定元变量，这可能是特定协议规范强制要求的。
The server MUST ensure that the script output is sent to the client unmodified. Note that this requires the script to use the correct character set (US-ASCII [9] and ISO 8859-1 [10] for HTTP) in the header fields. The server SHOULD attempt to ensure that the script output is sent directly to the client, with minimal internal and no transport-visible buffering.
服务器必须确保脚本输出未经修改发送到客户端。请注意，这要求脚本在头字段中使用正确的字符集（US-ASCII[9]和ISO 8859-1[10]用于HTTP）。服务器应尝试确保脚本输出直接发送到客户机，并使用最小的内部缓冲和无传输可见缓冲。
Unless the implementation defines otherwise, the script MUST NOT indicate in its response that the client can send further requests over the same connection.
除非实现另有定义，否则脚本不得在其响应中指示客户端可以通过同一连接发送更多请求。
A script MUST always provide a non-empty response, and so there is a system-defined method for it to send this data back to the server. Unless defined otherwise, this will be via the 'standard output' file descriptor.
脚本必须始终提供非空响应，因此有一个系统定义的方法将此数据发送回服务器。除非另有定义，否则这将通过“标准输出”文件描述符实现。
The script MUST check the REQUEST_METHOD variable when processing the request and preparing its response.
在处理请求和准备响应时，脚本必须检查REQUEST_METHOD变量。
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 the timeout period, the server MAY terminate the script process.
服务器可以实现一个超时周期，在此期间必须从脚本接收数据。如果服务器实现定义了这样一个超时，并且在超时期间没有从脚本接收到任何数据，则服务器可以终止脚本进程。
The response comprises a message-header and a message-body, separated by a blank line. The message-header contains one or more header fields. The body may be NULL.
响应包括消息头和消息体，由空行分隔。消息头包含一个或多个头字段。正文可能为空。
generic-response = 1*header-field NL [ response-body ]
generic-response = 1*header-field NL [ response-body ]
The script MUST return one of either 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.
脚本必须返回文档响应、本地重定向响应或客户端重定向（带有可选文档）响应之一。在下面的响应定义中，响应中标题字段的顺序并不重要（尽管在BNF中出现）。标题字段在第6.3节中定义。
CGI-Response = document-response | local-redir-response | client-redir-response | client-redirdoc-response
CGI响应=文件响应|本地重拨响应|客户端重拨响应|客户端重拨Doc响应
The CGI script can return a document to the user in a document response, with an optional error code indicating the success status of the response.
CGI脚本可以在文档响应中将文档返回给用户，并带有一个可选的错误代码，指示响应的成功状态。
document-response = Content-Type [ Status ] *other-field NL response-body
文档响应=内容类型[状态]*其他字段NL响应正文
The script MUST return a Content-Type header field. A Status header field is optional, and status 200 'OK' is assumed if it is omitted. 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.
脚本必须返回内容类型标题字段。状态标题字段是可选的，如果省略，则假定状态200为“OK”。服务器必须对脚本的输出进行任何适当的修改，以确保对客户端的响应符合响应协议版本。
The CGI script can return a URI path and query-string ('local-pathquery') for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.
CGI脚本可以在位置标头字段中为本地资源返回URI路径和查询字符串（“local-pathquery”）。这向服务器指示它应该使用指定的路径重新处理请求。
local-redir-response = local-Location NL
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
脚本不能返回任何其他头字段或消息体，服务器必须生成响应，该响应本应生成，以响应包含URL的请求
scheme "://" server-name ":" server-port local-pathquery
scheme "://" server-name ":" server-port local-pathquery
The CGI script can return an absolute URI path in a Location header field, to indicate to the client that it should reprocess the request using the URI specified.
CGI脚本可以在位置头字段中返回一个绝对URI路径，以指示客户端应该使用指定的URI重新处理请求。
client-redir-response = client-Location *extension-field NL
客户端重拨响应=客户端位置*扩展字段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.
除了服务器定义的CGI扩展字段外，脚本不得提供任何其他标题字段。对于HTTP客户端请求，服务器必须生成302“找到”HTTP响应消息。
The CGI script can return an absolute URI path in a Location header field together with an attached document, to indicate to the client that it should reprocess the request using the URI specified.
CGI脚本可以在Location标头字段中返回一个绝对URI路径以及一个附加文档，以指示客户端应该使用指定的URI重新处理请求。
client-redirdoc-response = client-Location Status Content-Type *other-field NL response-body
客户端redirdoc响应=客户端位置状态内容类型*其他字段NL响应正文
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.
必须提供Status header字段，该字段必须包含状态值302“Found”，或者它可能包含扩展代码，即表示客户端重定向的另一个有效状态代码。服务器必须对脚本的输出进行任何适当的修改，以确保对客户端的响应符合响应协议版本。
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 the syntax:
响应头字段是要由服务器解释的CGI或扩展头字段，或者是要包含在返回给客户端的响应中的特定于协议的头字段。必须至少提供一个CGI字段；每个CGI字段在响应中不得出现一次以上。响应标头字段具有以下语法：
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 )
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.
字段名不区分大小写。空字段值相当于未发送的字段。请注意，CGI响应中的每个标头字段必须在一行上指定；CGI/1.1不支持续行。在“：”和字段值之间（但不在字段名和“：”之间）以及字段值中的标记之间允许空白。
The Content-Type response field sets the Internet Media Type [6] of the entity body.
内容类型响应字段设置实体主体的互联网媒体类型[6]。
Content-Type = "Content-Type:" media-type NL
Content Type=“Content 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.
除非系统另有定义，否则如果协议为HTTP，则客户端对文本媒体类型假定的默认字符集为ISO-8859-1，否则为US-ASCII。因此，脚本应该包含一个字符集参数。有关此问题的讨论，请参见HTTP/1.1规范[4]的第3.4.1节。
The Location header field is used to specify to 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 is 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 header字段用于向服务器指定脚本返回对文档的引用，而不是实际文档的引用（请参见第6.2.3节和第6.2.4节）。它要么是一个绝对URI（可选带有片段标识符），表示客户端将获取引用的文档，要么是一个本地URI路径（可选带有查询字符串），表示服务器将获取引用的文档并将其作为响应返回给客户端。
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 = ":" | "@" | "&" | "=" | "+" | "$" | ","
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 "/".
绝对URI的语法与RFC 2396[2]和RFC 2732[7]中规定的语法合并到本文档中。有效的绝对URI始终以scheme的名称开头，后跟“：”；方案名称以字母开头，以字母数字“+”、“-”或“.”继续。本地URI路径和查询必须是绝对路径，而不是相对路径或NULL，因此必须以“/”开头。
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.
请注意，作为重定向目标的资源可能无法使用附加到请求（例如POST请求）的任何消息体。
The Status header field contains a 3-digit integer result code that indicates the level of success of the script's attempt to handle the request.
Status header字段包含一个3位整数结果代码，指示脚本尝试处理请求的成功级别。
Status = "Status:" status-code SP reason-phrase NL
status-code = "200" | "302" | "400" | "501" | extension-code
extension-code = 3digit
reason-phrase = *TEXT
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
状态代码200“OK”表示成功，是文档响应的默认值。状态代码302“已找到”与位置标头字段和响应消息正文一起使用。状态码
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.
400“错误请求”可能用于未知的请求格式，例如缺少内容类型。如果脚本接收到不受支持的请求\方法，则可能会返回状态代码501“未实现”。
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.
HTTP规范[1]、[4]第6.1.1节以及IANA HTTP状态代码注册表[8]中列出了其他有效的状态代码，这些状态代码可作为上述状态代码的补充或替代。在使用HTTP/1.1状态代码之前，脚本应检查服务器_协议的值。脚本可能会拒绝使用其不支持的方法发出的HTTP/1.1请求，错误为405“不允许使用方法”。
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.
原因短语是返回给客户机供用户使用的错误的文本描述。
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).
脚本可以返回与服务器_协议规范（HTTP/1.0[1]或HTTP/1.1[4]）定义的响应消息相关的任何其他头字段。如果不同，服务器必须将头数据从CGI头语法转换为HTTP头语法。例如，CGI脚本使用的换行符字符序列（例如UNIX的US-ASCII LF）可能与HTTP使用的字符序列不同（US-ASCII CR后跟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.
脚本不得返回任何与客户端通信问题相关的头字段，这些头字段可能会影响服务器向客户端发送响应的能力。服务器可以删除客户端返回的任何此类头字段。它应该解决脚本返回的头字段和它将发送给自己的头字段之间的任何冲突。
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.
可能还有其他实现定义的CGI头字段，其字段名称应以“X-CGI-”开头。服务器可以忽略（并删除）从脚本接收到的名称以“X-CGI-”开头的任何未识别的头字段。
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
response-body = *OCTET
Meta-Variables Meta-variables are passed to the script in identically named environment variables. These are accessed by 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.
元变量元变量在同名环境变量中传递给脚本。这些由DOS库例程GetVar（）访问。flags参数应为0。忽略大小写，但建议使用大写，以便与区分大小写的系统兼容。
The current working directory The current working directory for the script is set to the directory containing the script.
当前工作目录脚本的当前工作目录设置为包含脚本的目录。
Character set The US-ASCII character set [9] is used for the definition of meta-variables, header fields and values; the newline (NL) sequence is LF; servers SHOULD also accept CR LF as a newline.
字符集US-ASCII字符集[9]用于定义元变量、头字段和值；换行（NL）序列为LF；服务器还应接受CR LF作为换行符。
For UNIX compatible operating systems, the following are defined:
对于UNIX兼容的操作系统，定义了以下内容：
Meta-Variables Meta-variables are passed to the script in identically named environment variables. These are accessed by the C library routine getenv() or variable environ.
元变量元变量在同名环境变量中传递给脚本。这些由C库例程getenv（）或变量environ访问。
The command line This is accessed using the argc and argv arguments to main(). The words have any characters which are 'active' in the Bourne shell escaped with a backslash.
使用main（）的argc和argv参数访问命令行。这些单词在Bourne shell中有任何“活动”字符，并用反斜杠转义。
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], excluding NUL, is used for the definition of meta-variables, header fields and CHAR values; TEXT values use ISO-8859-1. The PATH_TRANSLATED value can contain any 8-bit byte except NUL. The newline (NL) sequence is LF; servers should also accept CR LF as a newline.
字符集US-ASCII字符集[9]，不包括NUL，用于定义元变量、头字段和字符值；文本值使用ISO-8859-1。路径_转换值可以包含除NUL以外的任何8位字节。换行（NL）序列为LF；服务器还应接受CR LF作为换行符。
For POSIX compatible operating systems using the EBCDIC character set, the following are defined:
对于使用EBCDIC字符集的POSIX兼容操作系统，定义如下：
Meta-Variables Meta-variables are passed to the script in identically named environment variables. These are accessed by the C library routine getenv().
元变量元变量在同名环境变量中传递给脚本。这些由C库例程getenv（）访问。
The command line This is accessed using the argc and argv arguments to main(). The words have any characters which are 'active' in the Bourne shell escaped with a backslash.
使用main（）的argc和argv参数访问命令行。这些单词在Bourne shell中有任何“活动”字符，并用反斜杠转义。
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], excluding NUL, is used for the definition of meta-variables, header fields, values, TEXT strings and the PATH_TRANSLATED value. The newline (NL) sequence is LF; servers should also accept CR LF as a newline.
字符集IBM1047字符集[21]，不包括NUL，用于定义元变量、标题字段、值、文本字符串和路径转换值。换行（NL）序列为LF；服务器还应接受CR LF作为换行符。
media-type charset default The default charset value for text (and other implementation-defined) media types is IBM1047.
媒体类型字符集默认文本（和其他实现定义的）媒体类型的默认字符集值为IBM1047。
Although the server and the CGI script need not be consistent in their handling of URL paths (client URLs and the PATH_INFO data, respectively), server authors may wish to impose consistency. So the server implementation should specify its behaviour for the following cases:
尽管服务器和CGI脚本在处理URL路径（分别是客户端URL和路径信息数据）时不需要保持一致，但服务器作者可能希望实现一致性。因此，服务器实现应针对以下情况指定其行为：
1. define any restrictions on allowed path segments, in particular whether non-terminal NULL segments are permitted;
1. 定义对允许的路径段的任何限制，特别是是否允许非终端空段；
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];
2. 定义“.”或“.”路径段的行为；i、 例如，它们是否被禁止、视为普通路径段或根据相关URL规范进行解释[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.
3. 定义实现的任何限制，包括对路径或搜索字符串长度的限制，以及对服务器将解析的头字段数量的限制。
If the script does not intend processing the PATH_INFO data, then it should reject the request with 404 Not Found if PATH_INFO is not NULL.
如果脚本不打算处理PATH_INFO数据，那么如果PATH_INFO不为NULL，它应该拒绝404 not Found请求。
If the output of a form is being processed, 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.
如果正在处理表单的输出，请检查内容类型是否为“application/x-www-form-urlencoded”[18]或“multipart/form data”[16]。如果CONTENT_TYPE为空，则脚本可以使用415“Unsupported Media TYPE”错误拒绝请求，该错误由协议支持。
When 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'.
分析路径信息、路径翻译或脚本名称时，脚本应注意无效路径段（“/”）和特殊路径段（“.”和“.”）。在OS系统调用中使用之前，应将它们从路径中删除，或者应使用404“未找到”拒绝请求。
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.
当返回头字段时，脚本应该尝试尽快发送CGI头字段，并且应该在任何HTTP头字段之前发送它们。这可能有助于减少服务器的内存需求。
Script authors should be aware that 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; that client may be a proxy, gateway, or other intermediary acting on behalf of the actual source client.
脚本作者应注意，远程添加和远程主机元变量（见第4.1.8节和第4.1.9节）可能无法识别请求的最终来源。它们标识向服务器发出即时请求的客户端；该客户端可以是代理、网关或代表实际源客户端的其他中介。
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.
正如HTTP规范[1]、[4]的安全注意事项中所讨论的，已经建立了约定，即GET和HEAD方法应该是“安全的”和“幂等的”（重复请求与单个请求具有相同的效果）。完整讨论见RFC 2616[4]第9.1节。
Some HTTP header fields may carry sensitive information which the server should not pass on to the script unless explicitly configured to do so. For example, if the server protects the script by using the Basic authentication scheme, then the client will send an Authorization header field containing a username and password. The server validates this information and so it should not pass on the password 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.
某些HTTP头字段可能包含敏感信息，服务器不应将这些信息传递给脚本，除非明确配置为这样做。例如，如果服务器使用基本身份验证方案保护脚本，则客户端将发送一个包含用户名和密码的授权标头字段。服务器验证此信息，因此未经仔细考虑，不应通过HTTP_授权元变量传递密码。这也适用于代理授权标头字段和相应的HTTP_Proxy_Authorization元变量。
Confidential data in a request should be placed in a message-body as part of a POST request, and not placed 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. In addition, many existing servers, proxies and clients will permanently record the URI where it might be visible to third parties.
请求中的机密数据应该作为POST请求的一部分放在消息体中，而不是放在URI或消息头中。在某些系统上，用于向脚本传递元变量的环境可能对其他脚本或用户可见。此外，许多现有的服务器、代理和客户机将永久记录第三方可能看到的URI。
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 is the server's responsibility to handle the TLS session, and thus it is the server which is authenticated to the client, not the CGI script.
对于使用TLS的客户端连接，安全模型应用于客户端和服务器之间，而不是客户端和脚本之间。处理TLS会话是服务器的责任，因此向客户机进行身份验证的是服务器，而不是CGI脚本。
This specification provides no mechanism for the script to authenticate the server which invoked it. There is no enforced integrity on the CGI request and response messages.
此规范不提供脚本对调用它的服务器进行身份验证的机制。CGI请求和响应消息上没有强制的完整性。
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.
最常见的CGI实现将脚本作为子进程调用，使用与服务器进程相同的用户和组。因此，应确保脚本不会干扰服务器进程、配置、文档或日志文件。
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.
如果通过调用链接到服务器软件的函数（在编译时或运行时）来执行脚本，则应采取预防措施保护服务器的核心内存，或确保不能执行不受信任的代码。
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. Use of 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).
此规范对呈现给脚本的消息体的长度没有限制。脚本不应假定任何大小的静态分配缓冲区都足以一次包含整个提交。在未仔细检查溢出的情况下使用固定长度的缓冲区可能会导致攻击者利用操作系统的“堆栈崩溃”或“堆栈溢出”漏洞进行攻击。脚本可能会将大量提交假脱机到磁盘或其他缓冲介质，但快速连续的大量提交可能会导致拒绝服务情况。如果消息正文的内容长度大于资源考虑所允许的长度，脚本应以适合协议版本的错误状态进行响应；可能适用的状态代码包括503“服务不可用”（HTTP/1.0和HTTP/1.1）、413“请求实体太大”（HTTP/1.1）和414“请求URI太大”（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; the server should not assume that statically allocated buffers of any size are sufficient to contain the entire response.
类似的考虑也适用于服务器处理来自脚本的CGI响应。脚本返回的头或消息体的长度没有限制；服务器不应假定任何大小的静态分配的缓冲区都足以包含整个响应。
The stateless nature of the Web makes each script execution and resource retrieval independent of all others even when multiple requests constitute 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 they are valid, both in form and content, before allowing them 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 is important that applications be protected from invalid input regardless of whether the invalidity is the result of user error, logic error, or malicious action.
Web的无状态特性使得每个脚本执行和资源检索独立于所有其他脚本，即使多个请求构成单个概念Web事务。因此，脚本不应该对提交请求的用户代理的上下文进行任何假设。特别是，脚本应该检查从客户端获得的数据，并验证它们在形式和内容上都是有效的，然后才允许将它们用于敏感目的，例如输入到其他应用程序、命令或操作系统服务。这些用途包括（但不限于）系统调用参数、数据库写入、动态评估的源代码以及计费或其他安全流程的输入。重要的是，无论无效输入是由用户错误、逻辑错误还是恶意操作造成的，都应保护应用程序不受无效输入的影响。
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. Subversion of this type occurs 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.).
涉及多请求事务的脚本作者在验证状态信息时应特别谨慎；用危险值替换提交文件中可能被认为安全的部分可能会产生不良影响。这种类型的Subversion发生在对来自交易的前一阶段的数据进行更改时，而这些更改不是由客户端控制的（例如，隐藏的HTML表单元素、cookie、嵌入的URL等）。
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.
服务器应该注意请求URI中的“.”路径段。在将请求URI拆分为脚本路径和额外路径之前，应该在请求URI中删除或解析这些路径。或者，当使用额外路径查找转换的路径时，应注意避免路径解析提供预期路径层次结构之外的转换路径。
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.
如果脚本返回未解析的头输出，由客户端在其本机协议中进行解释，则脚本必须解决与该协议相关的所有安全问题。
This work is based on the original CGI interface that arose 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.
这项工作基于最初的CGI接口，该接口源于对“www talk”邮件列表的讨论。尤其值得一提的是，Rob McCool、John Franks、Ari Lootonen、George Phillips和Tony Sanders在定义和实现该接口早期版本方面所做的努力值得特别认可。
This document has also greatly benefited from the comments and suggestions made Chris Adie, Dave Kristol and Mike Meyer; also David Morris, Jeremy Madea, Patrick McManus, Adam Donahue, Ross Patterson and Harald Alvestrand.
本文件还从Chris Adie、Dave Kristol和Mike Meyer提出的意见和建议中获益匪浅；还有大卫·莫里斯、杰里米·马迪亚、帕特里克·麦克马纳斯、亚当·多纳休、罗斯·帕特森和哈拉尔·阿尔韦斯特兰德。
[1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[1] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI) : Generic Syntax", RFC 2396, August 1998.
[2] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[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.
[5] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[7] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[7] Hinden，R.，Carpenter，B.，和L.Masinter，“URL中文字IPv6地址的格式”，RFC 2732，1999年12月。
[8] "HTTP Status Code Registry", http://www.iana.org/assignments/http-status-codes, IANA.
[8] “HTTP状态码注册表”，http://www.iana.org/assignments/http-status-codes，伊安娜。
[9] "Information Systems -- Coded Character Sets -- 7-bit American Standard Code for Information Interchange (7-Bit ASCII)", ANSI INCITS.4-1986 (R2002).
[9] “信息系统——编码字符集——信息交换用7位美国标准代码（7位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.
[10] “信息技术——8位单字节编码图形字符集——第1部分：拉丁字母表1”，ISO/IEC 8859-1:1998。
[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.
[11] Berners Lee，T.，“万维网中的通用资源标识符：万维网中使用的网络对象名称和地址表达的统一语法”，RFC 1630，1994年6月。
[12] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[12] Braden，R.，Ed.“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[13] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[13] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[14] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[15] Hinden R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[15] Hinden R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[16] Masinter, L., "Returning Values from Forms: multipart/form-data", RFC 2388, August 1998.
[16] Masinter，L.，“从表单返回值：多部分/表单数据”，RFC 23881998年8月。
[17] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[17] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[18] Raggett, D., Le Hors, A., and I. Jacobs, Eds., "HTML 4.01 Specification", W3C Recommendation December 1999, http://www.w3.org/TR/html401/.
[18] Raggett，D.，Le Hors，A.，和I.Jacobs，编辑，“HTML 4.01规范”，W3C建议，1999年12月，http://www.w3.org/TR/html401/.
[19] Rescola, E. "HTTP Over TLS", RFC 2818, May 2000.
[19] Rescola，E.“TLS上的HTTP”，RFC2818，2000年5月。
[20] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
[20] 圣约翰，M.，“身份确认协议”，RFC 1413，1993年2月。
[21] IBM National Language Support Reference Manual Volume 2, SE09-8002-01, March 1990.
[21] IBM国家语言支持参考手册第2卷，SE09-8002-01，1990年3月。
[22] "The Common Gateway Interface", http://hoohoo.ncsa.uiuc.edu/cgi/, NCSA, University of Illinois.
[22] “公共网关接口”，http://hoohoo.ncsa.uiuc.edu/cgi/，美国国家科学院，伊利诺伊大学。
David Robinson The Apache Software Foundation
Apache软件基金会David Robinson
EMail: drtr@apache.org
EMail: drtr@apache.org
Ken A. L. Coar The Apache Software Foundation
Apache软件基金会的肯恩·A·L·考尔
EMail: coar@apache.org
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。