Skip to main content

8. IANA注意事项 (IANA Considerations)

本规范更新了由[RFC2817]、[RFC2818]和[RFC4229]建立的注册表,此外还为方法名称、状态码和相关语义定义了新的注册表。

8.1. 方法注册 (Method Registration)

"超文本传输协议(HTTP)方法注册表"定义了请求方法令牌的命名空间(第4节)。方法注册表已创建,现在维护在http://www.iana.org/assignments/http-methods

8.1.1. 程序 (Procedure)

注册必须(MUST)包括以下字段:

  • 方法名称 (Method Name)
  • 安全性 (Safe) (是/否)
  • 幂等性 (Idempotent) (是/否)
  • 规范文本指针 (Pointer to specification text)

要添加到此命名空间的值需要IETF审查(参见[RFC5226]第4.1节)。

8.1.2. 新方法的考虑事项 (Considerations for New Methods)

标准化方法是通用的;也就是说,它们可能适用于任何资源,而不仅仅是一种特定的媒体类型、资源类型或应用程序。因此,首选在非特定于单一应用程序或数据格式的文档中注册新方法,因为正交技术值得正交规范。

由于消息解析([RFC7230]第3节)需要独立于方法语义(除了对HEAD的响应),新方法的定义不能改变解析算法或禁止在请求或响应消息上存在消息体。新方法的定义可以通过要求Content-Length头字段的值为"0"来指定只允许零长度消息体。

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

如果新方法是可缓存的,其定义应该(ought to)描述缓存如何以及在什么条件下可以存储响应并使用它来满足后续请求。新方法应该(ought to)描述它是否可以成为条件性的([RFC7232]第5节),如果可以,当条件为假时服务器如何响应。同样,如果新方法可能对部分响应语义([RFC7233])有一些用途,它也应该(ought to)记录这一点。

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

8.1.3. 注册 (Registrations)

根据本规范,HTTP的方法注册程序已更新。HTTP方法注册表已使用以下注册进行更新:

方法名称安全性幂等性参考
GET第4.3.1节
HEAD第4.3.2节
POST第4.3.3节
PUT第4.3.4节
DELETE第4.3.5节
CONNECT第4.3.6节
OPTIONS第4.3.7节
TRACE第4.3.8节

8.2. 状态码注册 (Status Code Registration)

"超文本传输协议(HTTP)状态码注册表"定义了响应状态码令牌的命名空间(第6节)。状态码注册表已创建,现在维护在http://www.iana.org/assignments/http-status-codes

8.2.1. 程序 (Procedure)

注册必须(MUST)包括以下字段:

  • 状态码 (Status Code) (3位数字)
  • 简短描述 (Short Description)
  • 规范文本指针 (Pointer to specification text)

要添加到HTTP状态码命名空间的值需要IETF审查(参见[RFC5226]第4.1节)。

8.2.2. 新状态码的考虑事项 (Considerations for New Status Codes)

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

新状态码必须属于第6节中定义的类别之一。为了允许现有解析器处理响应消息,新状态码不能禁止有效载荷,尽管它们可以要求零长度有效载荷体。

尚未广泛部署的新状态码提案应该(ought to)避免为代码分配特定编号,直到有明确共识将其注册;相反,早期草案可以使用诸如"4NN"或"3N0"之类的符号来指示建议状态码的类别,而不会过早地消耗编号。

新状态码的定义应该(ought to)解释具有该状态码的响应的语义,包括任何必需的前提条件、触发该状态的请求特征,以及处理此类响应的预期客户端行为。

8.2.3. 注册 (Registrations)

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

描述参考
100Continue第6.2.1节
101Switching Protocols第6.2.2节
200OK第6.3.1节
201Created第6.3.2节
202Accepted第6.3.3节
203Non-Authoritative Information第6.3.4节
204No Content第6.3.5节
205Reset Content第6.3.6节
206Partial Content[RFC7233], 第4.1节
300Multiple Choices第6.4.1节
301Moved Permanently第6.4.2节
302Found第6.4.3节
303See Other第6.4.4节
304Not Modified[RFC7232], 第4.1节
305Use Proxy第6.4.5节
306(Unused)第6.4.6节
307Temporary Redirect第6.4.7节
400Bad Request第6.5.1节
401Unauthorized[RFC7235], 第3.1节
402Payment Required第6.5.2节
403Forbidden第6.5.3节
404Not Found第6.5.4节
405Method Not Allowed第6.5.5节
406Not Acceptable第6.5.6节
407Proxy Authentication Required[RFC7235], 第3.2节
408Request Timeout第6.5.7节
409Conflict第6.5.8节
410Gone第6.5.9节
411Length Required第6.5.10节
412Precondition Failed[RFC7232], 第4.2节
413Payload Too Large第6.5.11节
414URI Too Long第6.5.12节
415Unsupported Media Type第6.5.13节
416Range Not Satisfiable[RFC7233], 第4.4节
417Expectation Failed第6.5.14节
426Upgrade Required第6.5.15节
500Internal Server Error第6.6.1节
501Not Implemented第6.6.2节
502Bad Gateway第6.6.3节
503Service Unavailable第6.6.4节
504Gateway Timeout第6.6.5节
505HTTP Version Not Supported第6.6.6节

8.3. 头字段注册 (Header Field Registration)

本规范使用[RFC3864]的注册程序更新了[RFC4229]中定义的HTTP头字段注册表。

8.3.1. 新头字段的考虑事项 (Considerations for New Header Fields)

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

新头字段至少需要定义:

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

记录以下内容也很有用:

  • 头字段是用于中介还是仅用于端到端
  • 安全和隐私考虑(参见第9节)
  • 与其他头字段的交互

"HTTP头字段规范指南"[RFC6648bis]中提供了定义新头字段的详细建议。

8.3.2. 注册 (Registrations)

位于http://www.iana.org/assignments/message-headers/的"超文本传输协议(HTTP)头字段注册表"应使用以下永久注册进行更新(参见[RFC3864]):

头字段名称协议状态参考
Accepthttpstandard第5.3.2节
Accept-Charsethttpstandard第5.3.3节
Accept-Encodinghttpstandard第5.3.4节
Accept-Languagehttpstandard第5.3.5节
Allowhttpstandard第7.4.1节
Content-Encodinghttpstandard第3.1.2.2节
Content-Languagehttpstandard第3.1.3.2节
Content-Locationhttpstandard第3.1.4.2节
Content-Typehttpstandard第3.1.1.5节
Datehttpstandard第7.1.1.2节
Expecthttpstandard第5.1.1节
Fromhttpstandard第5.5.1节
Locationhttpstandard第7.1.2节
Max-Forwardshttpstandard第5.1.2节
MIME-Versionhttpstandard附录A.1
Refererhttpstandard第5.5.2节
Retry-Afterhttpstandard第7.1.3节
Serverhttpstandard第7.4.2节
User-Agenthttpstandard第5.5.3节
Varyhttpstandard第7.1.4节

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

8.4. 内容编码注册 (Content Coding Registration)

"HTTP内容编码注册表"定义了内容编码名称的命名空间(第3.1.2.1节)。内容编码注册表已创建,现在维护在http://www.iana.org/assignments/http-parameters

8.4.1. 程序 (Procedure)

注册必须(MUST)包括以下字段:

  • 名称 (Name)
  • 描述 (Description)
  • 规范文本指针 (Pointer to specification text)

以"x-"开头的名称保留供私人使用([RFC5226]定义),因此无法注册。

要添加到此命名空间的值需要IETF审查(参见[RFC5226]第4.1节)。

8.4.2. 注册 (Registrations)

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

名称描述参考
compressUNIX "compress" 数据格式第3.1.2.1节
deflate"deflate" 压缩数据第3.1.2.1节
gzipGZIP 文件格式第3.1.2.1节
identity保留 (无编码的同义词)第3.1.2.1节