跳到主要内容

8. IANA 考虑事项

本规范更新由 [RFC2817], [RFC2818], 和 [RFC4229] 建立的注册表, 并为方法名称、状态码及其关联语义定义新的注册表.

8.1. 方法注册

"Hypertext Transfer Protocol (HTTP) Method Registry" 定义请求方法令牌的命名空间 (Section 4). 该方法注册表已经创建, 现在维护于 <http://www.iana.org/assignments/http-methods>.

8.1.1. 流程

注册项 MUST 包含以下字段:

  • Method Name
  • Safe (yes/no)
  • Idempotent (yes/no)
  • Pointer to specification text

要加入此命名空间的值需要 IETF Review (见 [RFC5226] Section 4.1).

8.1.2. 新方法的考虑事项

标准化方法是通用的; 也就是说, 它们可能适用于任何资源, 而不只是某一种特定媒体类型、资源类别或应用程序. 因此, 最好在不专属于单个应用程序或数据格式的文档中注册新方法, 因为正交技术应有正交的规范.

由于消息解析 ([RFC7230] Section 3) 需要独立于方法语义 (对 HEAD 的响应除外), 新方法的定义不能改变解析算法, 也不能禁止请求消息或响应消息中出现消息体. 新方法的定义可以通过要求 Content-Length 头部字段值为 "0", 来规定只允许零长度消息体.

新方法定义需要说明它是否安全 (Section 4.2.1)、幂等 (Section 4.2.2)、可缓存 (Section 4.2.3), 请求消息体 (如果有) 应关联什么语义, 以及响应消息体 (如果有) 应关联什么语义. 注意, 请求方法的幂等性是源服务器上实现的属性. 由于实现可能偏离预期行为, 客户端不能依赖某个方法一定是幂等或安全的.

如果新方法可缓存, 其定义应描述缓存如何以及在什么条件下可以存储响应并用它满足后续请求. 新方法应描述它是否可以被设为条件式 ([RFC7232] Section 5), 如果可以, 还应描述当条件为假时服务器如何响应. 同样, 如果新方法可能会用到部分响应语义 ([RFC7233]), 也应对此加以记录.

注意: 避免定义以 "M-" 开头的方法名称, 因为该前缀可能被误解为具有 [RFC2774] 赋予它的语义.

8.1.3. 注册项

HTTP 的方法注册流程已按本规范更新. HTTP Method Registry 已使用以下注册项更新:

Method NameSafeIdempotentReference
GETyesyesSection 4.3.1
HEADyesyesSection 4.3.2
POSTnonoSection 4.3.3
PUTnoyesSection 4.3.4
DELETEnoyesSection 4.3.5
CONNECTnonoSection 4.3.6
OPTIONSyesyesSection 4.3.7
TRACEyesyesSection 4.3.8

8.2. 状态码注册

"Hypertext Transfer Protocol (HTTP) Status Code Registry" 定义响应 status-code 令牌的命名空间 (Section 6). 该状态码注册表已经创建, 现在维护于 http://www.iana.org/assignments/http-status-codes.

8.2.1. 流程

注册项 MUST 包含以下字段:

  • Status Code (3 digits)
  • Short Description
  • Pointer to specification text

要加入 HTTP 状态码命名空间的值需要 IETF Review (见 [RFC5226] Section 4.1).

8.2.2. 新状态码的考虑事项

当需要表达当前状态码未定义的响应语义时, 可以注册新的状态码. 状态码是通用的; 它们可能适用于任何资源, 而不只是某一种特定媒体类型、资源类别或 HTTP 应用. 因此, 最好在不专属于单个应用程序的文档中注册新状态码.

新状态码必须归入 Section 6 中定义的某一类别. 为了允许现有解析器处理响应消息, 新状态码不能禁止负载, 但可以强制要求零长度负载体.

对于尚未广泛部署的新状态码提案, 在明确达成将注册该状态码的共识之前, 应避免为其分配具体编号; 早期草案可以改用 "4NN" 或 "3N0" 这样的记法来指示拟议状态码的类别, 避免过早消耗编号.

新状态码的定义应说明具有该状态码的响应语义, 包括任何必需的前置条件、触发该状态的请求特征, 以及处理此类响应时预期的客户端行为.

8.2.3. 注册项

状态码注册表已使用以下注册项更新:

ValueDescriptionReference
100ContinueSection 6.2.1
101Switching ProtocolsSection 6.2.2
200OKSection 6.3.1
201CreatedSection 6.3.2
202AcceptedSection 6.3.3
203Non-Authoritative InformationSection 6.3.4
204No ContentSection 6.3.5
205Reset ContentSection 6.3.6
206Partial Content[RFC7233], Section 4.1
300Multiple ChoicesSection 6.4.1
301Moved PermanentlySection 6.4.2
302FoundSection 6.4.3
303See OtherSection 6.4.4
304Not Modified[RFC7232], Section 4.1
305Use ProxySection 6.4.5
306(Unused)Section 6.4.6
307Temporary RedirectSection 6.4.7
400Bad RequestSection 6.5.1
401Unauthorized[RFC7235], Section 3.1
402Payment RequiredSection 6.5.2
403ForbiddenSection 6.5.3
404Not FoundSection 6.5.4
405Method Not AllowedSection 6.5.5
406Not AcceptableSection 6.5.6
407Proxy Authentication Required[RFC7235], Section 3.2
408Request TimeoutSection 6.5.7
409ConflictSection 6.5.8
410GoneSection 6.5.9
411Length RequiredSection 6.5.10
412Precondition Failed[RFC7232], Section 4.2
413Payload Too LargeSection 6.5.11
414URI Too LongSection 6.5.12
415Unsupported Media TypeSection 6.5.13
416Range Not Satisfiable[RFC7233], Section 4.4
417Expectation FailedSection 6.5.14
426Upgrade RequiredSection 6.5.15
500Internal Server ErrorSection 6.6.1
501Not ImplementedSection 6.6.2
502Bad GatewaySection 6.6.3
503Service UnavailableSection 6.6.4
504Gateway TimeoutSection 6.6.5
505HTTP Version Not SupportedSection 6.6.6

8.3. 头部字段注册

本规范使用 [RFC3864] 的注册流程更新 [RFC4229] 中定义的 HTTP-header 字段注册表.

8.3.1. 新头部字段的考虑事项

头部字段是 HTTP 可扩展性框架的关键组成部分. 它们定义与消息或资源相关联的附加数据. 定义新头部字段时需要考虑许多事项.

新头部字段至少需要定义:

  1. 字段名称 ([RFC7230] Section 3.2)
  2. 字段值的预期语法
  3. 字段的语义
  4. 对于请求头部字段, 它们如何覆盖或增强消息语义
  5. 对于响应头部字段, 它们如何修改对响应的解释
  6. 字段是否应由缓存存储, 以及是否可以在对后续请求的响应中返回
  7. 字段是否应由代理转发

记录以下内容也很有用:

  • 头部字段是供中间方使用, 还是仅用于端到端
  • 安全和隐私考虑事项 (见 Section 9)
  • 与其他头部字段的交互

有关定义新头部字段的详细建议见 "Guidelines for HTTP Header Field Specifications" [RFC6648bis].

8.3.2. 注册项

位于 http://www.iana.org/assignments/message-headers/ 的 "Hypertext Transfer Protocol (HTTP) Header Field Registry" 应使用以下永久注册项更新 (见 [RFC3864]):

Header Field NameProtocolStatusReference
AccepthttpstandardSection 5.3.2
Accept-CharsethttpstandardSection 5.3.3
Accept-EncodinghttpstandardSection 5.3.4
Accept-LanguagehttpstandardSection 5.3.5
AllowhttpstandardSection 7.4.1
Content-EncodinghttpstandardSection 3.1.2.2
Content-LanguagehttpstandardSection 3.1.3.2
Content-LocationhttpstandardSection 3.1.4.2
Content-TypehttpstandardSection 3.1.1.5
DatehttpstandardSection 7.1.1.2
ExpecthttpstandardSection 5.1.1
FromhttpstandardSection 5.5.1
LocationhttpstandardSection 7.1.2
Max-ForwardshttpstandardSection 5.1.2
MIME-VersionhttpstandardAppendix A.1
RefererhttpstandardSection 5.5.2
Retry-AfterhttpstandardSection 7.1.3
ServerhttpstandardSection 7.4.2
User-AgenthttpstandardSection 5.5.3
VaryhttpstandardSection 7.1.4

变更控制者为: "IETF ([email protected]) - Internet Engineering Task Force".

8.4. 内容编码注册

"HTTP Content Coding Registry" 定义内容编码名称的命名空间 (Section 3.1.2.1). 该内容编码注册表已经创建, 现在维护于 http://www.iana.org/assignments/http-parameters.

8.4.1. 流程

注册项 MUST 包含以下字段:

  • Name
  • Description
  • Pointer to specification text

以 "x-" 开头的名称保留给 Private Use (按 [RFC5226] 定义), 因此不能注册.

要加入此命名空间的值需要 IETF Review (见 [RFC5226] Section 4.1).

8.4.2. 注册项

内容编码注册表已使用以下注册项更新:

NameDescriptionReference
compressUNIX "compress" data formatSection 3.1.2.1
deflate"deflate" compressed dataSection 3.1.2.1
gzipGZIP file formatSection 3.1.2.1
identityReserved (synonym for no encoding)Section 3.1.2.1