8. IANA 考量
8.1. 头部字段登记
HTTP 头部字段登记在维护于 http://www.iana.org/assignments/message-headers/ 的 "Message Headers" 注册表中.
本文档定义了以下 HTTP 头部字段, 因此 "Permanent Message Header Field Names" 注册表已相应地得到更新 (见 [BCP90]).
+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+
| Connection | http | standard | Section 6.1 |
| Content-Length | http | standard | Section 3.3.2 |
| Host | http | standard | Section 5.4 |
| TE | http | standard | Section 4.3 |
| Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+
此外, 头部字段名 "Close" 已被登记为 "reserved", 因为把这个名字用作 HTTP 头部字段可能与 Connection 头部字段的 "close" 连接选项冲突 (第 6.1 节).
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 |
+-------------------+----------+----------+-------------+
变更控制者是: "IETF ([email protected]) - Internet Engineering Task Force".
8.2. URI 方案登记
IANA 在 http://www.iana.org/assignments/uri-schemes/ 维护 URI 方案注册表 [BCP115].
本文档定义了以下 URI 方案, 因此 "Permanent URI Schemes" 注册表已相应地得到更新.
+------------+------------------------------------+---------------+
| URI Scheme | Description | Reference |
+------------+------------------------------------+---------------+
| http | Hypertext Transfer Protocol | Section 2.7.1 |
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
+------------+------------------------------------+---------------+
8.3. 互联网媒体类型登记
IANA 在 http://www.iana.org/assignments/media-types 维护互联网媒体类型注册表 [BCP13].
本文档作为互联网媒体类型 "message/http" 和 "application/http" 的规范. 以下内容已向 IANA 登记.
8.3.1. 互联网媒体类型 message/http
message/http 类型可用于封装单条 HTTP 请求或响应消息, 前提是它遵守所有 "message" 类型在行长和编码方面的 MIME 限制.
Type name: message
Subtype name: http
Required parameters: N/A
Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
Security considerations: see Section 9
Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.1).
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information:
Magic number(s): N/A
Deprecated alias names for this type: N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: IESG
8.3.2. 互联网媒体类型 application/http
application/http 类型可用于封装由一条或多条 HTTP 请求或响应消息 (不混合) 构成的流水线.
Type name: application
Subtype name: http
Required parameters: N/A
Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
Encoding considerations: HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via email.
Security considerations: see Section 9
Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: IESG
8.4. 传输编码注册表
"HTTP Transfer Coding Registry" 定义了传输编码名称的命名空间. 它维护于 http://www.iana.org/assignments/http-parameters.
8.4.1. 流程
登记 MUST 包含以下字段:
-
Name
-
Description
-
Pointer to specification text
除非编码变换完全相同 (如第 4.2 节定义的压缩编码那样), 否则传输编码的名称 MUST NOT 与内容编码的名称重叠 ([RFC7231] 第 3.1.2.1 节).
要加入该命名空间的值需要经过 IETF Review (见 [RFC5226] 第 4.1 节), 并且 MUST 符合本规范所定义的传输编码用途.
用程序名来标识编码格式并不可取, 对于未来的编码也不鼓励这样做.
8.4.2. 登记
"HTTP Transfer Coding Registry" 已按以下登记得到更新:
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| chunked | Transfer in a series of chunks | Section 4.1 |
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
8.5. 内容编码登记
IANA 在 http://www.iana.org/assignments/http-parameters 维护 "HTTP Content Coding Registry".
"HTTP Content Coding Registry" 已按以下登记得到更新:
+------------+--------------------------------------+---------------+
| Name | Description | Reference |
+------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+
8.6. Upgrade 令牌注册表
"Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" 定义了用于在 Upgrade 头部字段中标识协议的 protocol-name token 命名空间. 该注册表维护于 http://www.iana.org/assignments/http-upgrade-tokens.
8.6.1. 流程
每个已登记的协议名都与联系信息以及一组可选的规范相关联, 这些规范详细说明连接在升级之后将如何处理.
登记按 "First Come First Served" 原则进行 (见 [RFC5226] 第 4.1 节), 并遵循以下规则:
-
一个 protocol-name token 一经登记, 就永久保持已登记状态.
-
登记 MUST 指明该登记的责任方.
-
登记 MUST 指明一个联系点.
-
登记 MAY 指明与该 token 相关联的一组规范. 这类规范不必公开可得.
-
登记 SHOULD 指明登记时与该 token 相关联的一组预期的 "protocol-version" token.
-
责任方 MAY 在任何时候变更登记. IANA 将保留所有此类变更的记录, 并应请求提供这些记录.
-
IESG MAY 重新分配某个协议 token 的责任. 这通常只在无法联系到责任方的情况下使用.
这一 HTTP Upgrade Token 登记流程取代了先前在 [RFC2817] 第 7.2 节中定义的流程.
8.6.2. Upgrade 令牌登记
升级令牌注册表中的 "HTTP" 条目已按以下登记得到更新:
+-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference |
| | | Tokens | |
+-------+----------------------+----------------------+-------------+
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
| | Protocol | (e.g, "2.0") | |
+-------+----------------------+----------------------+-------------+
责任方是: "IETF ([email protected]) - Internet Engineering Task Force".