请求方式
CONNECT
在 HTTP 协议中，CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通。它可以用来创建隧道（tunnel）。
例如，CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流。
CONNECT 是一个点对点的连接。它是一个没有实体的请求，但是能够成功请求到响应，同时也是一种不安全、不可缓存、无法运用到 HTML 表单上和非幂等的的一种请求连接方式。
示例
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
DELECT
HTTP DELECT 请求方法用于删除指定的资源。
| 请求是否有主体 | 可以有 |
| 成功的返回是否有主体 | 可以有 |
| 安全 | 否 |
| 幂等 | 是 |
| 可缓存 | 否 |
| 可以在HTML forms中使用 | 否 |
示例
请求
DELECT /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
GET 方法是根据一个资源地址进行资源访问，该方式的请求只用于获取数据。
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 是 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| HTML 表单是否支持 | 是 |
语法
GET /index.html HTTP/1.1
HEAD
HEAD 方法是在请求大的资源之前发送的一个请求，该请求的响应会返回请求资源的大小，判断是否要下载该资源，可以节省宽带。该方法请求资源的头部信息和 GET 方式请求的返回一致。
HEAD 方法响应不应该包过正文部分，即使有正文部分也会被隐藏，虽然描述正文的响应头部可能会包含 Content-Length 但是这是给描述相同情况下 GET 请求的。
如果 HEAD 请求结果显示在上一次 GET 请求后缓存的资源已经过期了，那么该缓存会失效，即使 GET 请求已经完成。
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 否 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 是 |
| HTML 表单是否支持 | 否 |
语法
HEAD /index.html HTTP/1.1
OPTIONS
OPTIONS 方法用于获取目的资源所支持的通信方式，客户端可以通过指定 URL 或者用 * 表示对整个服务站使用 OPTIONS 方法。
| 请求是否有主体 | 否 |
| 成功的响应是否有主体 | 否 |
| 安全 | 是 |
| 幂等 | 是 |
| 可缓存 | 否 |
| HTML 表单是否支持 | 否 |
语法
OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
示例
检测服务器所支持的请求方式
可以使用 OPTIONS 方法对服务器发起请求，已检测服务器支持哪些 HTTP 方法：
curl -X OPTIONS http://example.org -i
随后服务端会响应成功，其中会带有 Allow 属性。Allow 属性中所有的方法就是该资源允许的访问方式。
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 的预检请求，是为了检测在跨域情况下，实际请求是否被允许。首先这个请求必须带有一个 Origin 告诉服务器这个请求来自哪里，这样才能够继续预检请求。服务器会根据预检请求中的 Access-Control-Request-Method、Access-Control-Request-Headers 来判断是否接受实际请求，其中还会通过 Access-Control-Request-Credentials 来判断是否带有 Cookie 属性。
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-Request-Credentials: true
服务器返回 Access-Control-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
PATCH 方式是一种非等幂的请求方式，这种方式每次请求都会产生不同的结果，PUT 代表着一种覆盖文件请求方式，而 POST 请求方式又不带有补丁一说的性质。
我们可以通过响应头中的 Allow 、Allow-Control-Request-Method（CORS 跨域）中查看服务器支不支持 PATCH 请求方式。响应头还有一个隐式属性 Accept-Patch 表示接受补丁文件的格式。
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 否 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | 否 |
| HTML 表单是否支持 | 否 |
语法
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
POST 方式发送数据给服务器，请求主题由 Content-Type 属性来决定，POST 是一个非幂等请求方式。
如果 POST 请求通过 HTML 表单提交，其需要设置 enctype 属性，如果是 input 、button 标签的时候需要设置 formenctype 属性。
-
- applicationc/xxx-form-urlencoded : 数据被编码成以 & 分割的对子键模式，以 = 分割的 key value 的模式，非字母和数字字符会被提前 precent-encoding，这也是为什么这种类型不支持二进制数据。（应该用 multipart/form-data 代替）。
-
- multipart/form-data
-
- text/plain
当 POST 请求时通过除了 HTML 表单的其他方式发送请求的，例如 fetch XMLHttpRequest，那么任何 Content-Type 都可以设置。
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 是 |
| 安全 | 否 |
| 幂等 | 否 |
| 可缓存 | 当时新数据时才缓存 |
| HTML 表单是否支持 | 否 |
语法
POST /index.html HTTP/1.1
示例
使用默认的 application/xxx-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 请求方式是一种 创建、覆盖目标资源的操作。如果服务器没有这个资源，该资源将会被创建，如果服务器由该资源，那么这个资源将会被覆盖。
| 请求是否有主体 | 是 |
| 成功的响应是否有主体 | 否 |
| 安全 | 否 |
| 幂等 | 是 |
| 可缓存 | 否 |
| HTML 表单是否支持 | 否 |
语法
PUT /text.txt HTTP/1.1
示例
请求
PUT /text.txt HTTP/1.1
Host： example.com
Content-type: text/plain
Content-length: 10
hello world
响应
如果是被创建，需要返回 201 Created 状态码
HTTP/1.1 201 Created
Content-Location: /text.txt
如果是被覆盖的，需要返回 200（ok） 或者 204 No Content
HTTP/1.1 204 No Content
Content-Location: /text.txt
3522
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
