有多少种HTTP动词？

Question

我数了一下，一共有 9 种HTTP 请求方法（也称为动词）：

GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH

以上来源于：https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

就这些了吗？这会改变吗？

- Purplejacket

---

注意：我知道正式来说这些是“HTTP请求方法”，但我也看到它们被称为“动词”，就像上面的链接所描述的那样。 - Purplejacket

从技术上讲，任何事情都有可能发生。似乎有一些恶意软件试图通过虚构的“动词”传输数据 - 在某些情况下，该动词看起来像一个非常长的（稍微混淆的）base64字符串。现在，这样的东西并不是任何RFC中定义的HTTP。但它可能会出现在您的网络跟踪中。 - Klaws

Answer 1

注册表

HTTP 1.1 规范定义了一个超文本传输协议（HTTP）方法注册表。截至2017年1月，共显示39个条目：

• ACL
• 基线控制
• BIND
• CHECKIN
• CHECKOUT
• 连接
• COPY
• 删除
• 获取
• 头部信息
• 标签
• 链接
• 锁定
• 合并
• MKACTIVITY
• MKCALENDAR
• MKCOL
• MKREDIRECTREF
• MKWORKSPACE
• 移动
• 选项
• ORDERPATCH
• PATCH
• 发布
• PRI
• PROPFIND
• PROPPATCH
• 放置
• 重新绑定
• 报告
• 搜索
• 跟踪
• 解除绑定
• 取消签出
• 取消链接
• 解锁
• 更新
• UPDATEREDIRECTREF
• 版本控制

HTTP 1.0

HTTP 1.0 定义了三种方法（“动词”）：

• GET
  … 检索由请求URI标识的任何信息…
• POST
  … 请求目标服务器接受请求中包含的实体作为请求行中请求URI标识的资源的新下属… 在公告板、新闻组、邮件列表上发布消息… 提供一块数据… 通过追加操作扩展数据库…
• HEAD
  … 与GET相同，除了服务器不得在响应中返回消息正文… 用于获取有关请求所暗示的实体的元信息，而不传输实体正文本身…

HTTP 1.1

HTTP 1.1 在 RFC 2068 中正式定义。此规范添加了五种更多的方法。

• OPTIONS
  ...请求有关请求/响应链上可用通信选项的信息...确定与资源相关的选项和/或要求，或服务器的功能，而不意味着资源操作或启动资源检索。
• PUT
  ...请求将封装实体存储在提供的请求URI下。如果...已经存在的资源，则应将封装实体视为驻留在原始服务器上的修改版本...
• DELETE
  ...删除由请求URI标识的资源...
• TRACE
  ...请求消息的回路...
• CONNECT
  ...用于可以动态切换为隧道的代理（例如SSL隧道）...

HTTP扩展

其他协议扩展HTTP以定义其他方法/动词。

• 修补
• 对资源应用部分修改
• 由RFC 5789定义
• WebDAV指定了另外七种方法：
  • PROPFIND
  • PROPPATCH
  • MKCOL
  • COPY
  • MOVE
  • LOCK
  • UNLOCK

HTTP/2

HTTP/2在RFC 7540中定义。 第3.5节定义了一个PRI方法。

• PRI
  在HTTP/2中，每个端点都需要发送连接前缀作为协议使用的最终确认，并建立HTTP/2连接的初始设置。...连接前缀以字符串“PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n”开头...

预测

这会改变吗？

不太可能。

鉴于Web RPC和SOAP的广泛使用，以及现在RESTful服务的日益流行，为现有基本动词带来新生命，几乎没有必要在HTTP级别上设计新动词。当人们需要自己的领域特定的有意义的动词时，可以将其嵌入通过HTTP传递的消息中。

我预计我们不会很快看到更多流行的HTTP方法。

- Basil Bourque

---

关于HTTP/2：https://http2.github.io表示“HTTP方法、状态码和语义相同”，因此似乎HTTP/2不会引入任何新的请求方法（“动词”），尽管在规范中我确实看到了PRI方法的提及：“这种方法从未被实际客户端使用。当HTTP/1.1服务器或中介尝试解析HTTP/2连接前缀时，该方法将似乎被使用。” - Purplejacket

感谢提供注册表链接。但是HTTP 1.0/1.1的分发方式是错误的。RFC 1945声明：GET，HEAD，POST，PUT，DELETE，LINK和UNLINK是适用于HTTP 1.0的有效方法。 - puchu

@puchu RFC 1945（HTTP 1.0）仅声明了前三个：GET，HEAD，POST。其他四个仅在附录中提到。引用一下：“本附录记录了一些现有的HTTP实现使用的协议元素，但大多数HTTP / 1.0应用程序之间没有一致和正确的使用。实现者应该知道这些特性，但不能依赖它们在互操作性方面的存在。” - Basil Bourque

所以我们可以将 GET、HEAD 和 POST 声明为严格的，而将其他的声明为非严格的。 - puchu

@puchu 不，我们可以说那时有三个被标准化了，其他动词都是实验性的。那时是网络的“西部荒野”时期，各种人尝试各种事情。有些东西被保留并最终标准化，而其他东西则消失了。 - Basil Bourque

Answer 2

查看规范：

“本规范之外的其他方法已经被标准化用于HTTP。所有这些方法都应在由IANA维护的“Hypertext Transfer Protocol (HTTP) Method Registry”中注册，如第8.1节所定义。”--https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.1.p.7

而IANA注册表还包含许多其他方法。

- Julian Reschke

---

我在http://www.iana.org/assignments/http-methods/http-methods.xhtml找到了IANA注册表，截至2017年1月，其中提到了39种方法。其中有相当多的方法来自WebDAV或WebDAV的扩展。我注意到LINK和UNLINK与HTTP 1.1有关，PRI与HTTP/2有关。 - Purplejacket