一：CONNECT
在 HTTP 协议中，CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道（tunnel）。
例如，CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流。
CONNECT 是一个应用范围为点到点的方法。
| Request has body | No |
|---|---|
| Successful response has body | Yes |
| Safe | No |
| Idempotent | No |
| Cacheable | No |
| Allowed in HTML forms | No |
语法
CONNECT www.example.com:443 HTTP/1.1
示例
一些代理服务器在创建隧道时会要求进行身份验证。参见 Proxy-Authorization 首部。
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
规范
| Specification | Title |
|---|---|
| RFC 7231, section 4.3.6: CONNECT | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
二:DELETE
HTTP DELETE 请求方法用于删除指定的资源。
| 请求是否有主体 | 可以有 |
|---|---|
| 成功的返回是否有主体 | 可以有 |
| 安全 | 否 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 可以在HTML forms中使用 | 否 |
语法
DELETE /file.html HTTP/1.1
示例
请求
DELETE /file.html HTTP/1.1
响应
如果 DELETE 方法成功执行，那么可能会有以下几种状态码：
- 状态码
202(Accepted) 表示请求的操作可能会成功执行，但是尚未开始执行。 - 状态码
204(No Content) 表示操作已执行，但是无进一步的相关信息。 - 状态码
200(OK) 表示操作已执行，并且响应中提供了相关状态的描述信息。
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT
<html>
<body>
<h1>File deleted.</h1>
</body>
</html>
三GET
HTTP GET 方法请求指定的资源。使用 GET 的请求应该只用于获取数据。
| 请求是否有主体 | 否 |
|---|---|
| 成功的响应是否有主体 | 是 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| HTML 表单是否支持 | 是 |
语法
GET /index.html
四:HEAD
HTTP HEAD 方法 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源.
HEAD 方法的响应不应包含响应正文. 即使包含了正文也必须忽略掉. 虽然描述正文信息的 entity headers, 例如 Content-Length 可能会包含在响应中, 但它们并不是用来描述 HEAD 响应本身的, 而是用来描述同样情况下的 GET 请求应该返回的响应.
如果 HEAD 请求的结果显示在上一次 GET 请求后缓存的资源已经过期了, 即使没有发出GET请求，缓存也会失效
| 请求是否有正文 | 否 |
|---|---|
| 成功的响应是否有正文 | 否 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| HTML 表单 是否支持 | 否 |
语法
HEAD /index.html
五：OPTIONS
HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。
| Request has body | No |
|---|---|
| Successful response has body | Yes |
| Safe | Yes |
| Idempotent | Yes |
| Cacheable | No |
| Allowed in HTML forms | No |
语法
OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
示例
检测服务器所支持的请求方法
可以使用 OPTIONS 方法对服务器发起请求，以检测服务器支持哪些 HTTP 方法：
curl -X OPTIONS http://example.org -i
响应报文包含一个 Allow 首部字段，该字段的值表明了服务器支持的所有 HTTP 方法：
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
CORS 中的预检请求
在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
服务器所返回的 Access-Control-Allow-Methods 首部字段将所有允许的请求方法告知客户端。该首部字段与 Allow 类似，但只能用于涉及到 CORS 的场景中。
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
六:PATCH
在HTTP协议中，请求方法 PATCH 用于对资源进行部分修改。
在HTTP协议中， PUT 方法已经被用来表示对资源进行整体覆盖， 而 POST 方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法，而与 POST 方法类似，PATCH 方法是非幂等的，这就意味着连续多个的相同请求会产生不同的效果。
要判断一台服务器是否支持 PATCH 方法，那么就看它是否将其添加到了响应首部 Allow 或者 Access-Control-Allow-Methods （在跨域访问的场合，CORS）的方法列表中 。
另外一个支持 PATCH 方法的隐含迹象是 Accept-Patch 首部的出现，这个首部明确了服务器端可以接受的补丁文件的格式。
| Request has body | Yes |
|---|---|
| Successful response has body | No |
| Safe | No |
| Idempotent | No |
| Cacheable | No |
| Allowed in HTML forms | No |
语法
PATCH /file.txt HTTP/1.1
示例
请求
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
响应
204 状态码表示这是一个操作成功的响应，因为响应中不带有消息主体。
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
七:POST
HTTP POST 方法 发送数据给服务器. 请求主体的类型由 Content-Type 首部指定.
PUT和POST方法的区别是,PUT方法是幂等的：连续调用一次或者多次的效果相同（无副作用）。连续调用同一个POST可能会带来额外的影响，比如多次提交订单。
一个 POST 请求通常是通过 HTML 表单发送, 并返回服务器的修改结果. 在这种情况下, content type 是通过在 ](https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/form) 元素中设置正确的 `enctype` 属性, 或是在 [ 和 `` 元素中设置 formenctype 属性来选择的:
application/``x-www-form-urlencoded: 数据被编码成以'&'分隔的键-值对, 同时以'='分隔键和值. 非字母或数字的字符会被 percent-encoding: 这也就是为什么这种类型不支持二进制数据(应使用multipart/form-data代替).multipart/form-datatext/plain
当 POST 请求是通过除 HTML 表单之外的方式发送时, 例如使用 XMLHttpRequest, 那么请求主体可以是任何类型.按HTTP 1.1规范中描述，POST为了以统一的方法来涵盖以下功能：
- 注释已有的资源
- 在公告板，新闻组，邮件列表或类似的文章组中发布消息;
- 通过注册新增用户;
- 向数据处理程序提供一批数据，例如提交一个表单;
- 通过追加操作，扩展数据库数据.
| 请求是否有主体 | 是 |
|---|---|
| 成功的响应是否有主体 | 是 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | Only if freshness information is included |
| HTML 表单是否支持 | 是 |
语法
POST /index.html
示例
使用默认的 application/x-www-form-urlencoded 做为 content type 的简单表单:
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
say=Hi&to=Mom
使用 multipart/form-data 作为 content type 的表单:
POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"
--boundary
Content-Disposition: form-data; name="field1"
value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"
value2
八:PUT
PUT 与 POST 方法的区别在于，PUT方法是幂等的：调用一次与连续调用多次是等价的（即没有副作用），而连续调用多次POST方法可能会有副作用，比如将一个订单重复提交多次。
| Request has body | Yes |
|---|---|
| Successful response has body | No |
| Safe | No |
| Idempotent | Yes |
| Cacheable | No |
| Allowed in HTML forms | No |
语法
PUT /new.html HTTP/1.1
九:TRACE
HTTP TRACE 方法 实现沿通向目标资源的路径的消息环回（loop-back）测试 ，提供了一种实用的 debug 机制。
请求的最终接收者应当原样反射（reflect）它接收到的消息，除了以下字段部分，作为一个Content-Type 为 message/http 的200（OK）响应的消息的主体（body）返回给客户端 。
最终接收者是指初始（origin）服务器，或者第一个接收到 Max-Forwards 值为 0的请求的服务器。
| 有主体（body）的请求（request） | 否 |
|---|---|
| 包含主体（body）的成功的响应（response） | 否 |
| Safe | 否 |
| Idempotent | 是 |
| Cacheable | 否 |
| 允许用于 HTML 表单（form） | 否 |
语法
TRACE /index.html