HTTP 请求方法

介绍

HTTP 方法（也称为 HTTP 请求方法）是客户端与服务器进行交互时指定操作类型的方式，每个 HTTP 方法对应着不同的操作，如获取数据、修改数据、删除数据等。常见的 HTTP 方法包括 GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS 和 TRACE。

请求和响应的格式

上图来自 HTTP messages - HTTP | MDN

HTTP 请求和响应消息遵循一个相似的结构，通常包括以下几个部分：

起始行（Start-Line）

起始行是单独的一行，描述了 HTTP 版本以及请求方法或请求结果的状态。

• 对于请求，起始行包含 HTTP 方法（如 GET、POST 等）以及请求的资源路径。
• 对于响应，起始行包含 HTTP 版本和响应状态码，以及描述请求结果的简短消息。

HTTP 标头（Headers）

紧接着起始行的是一个可选的 HTTP 标头部分，包含了描述消息元数据的各种字段。

• 在请求中，标头可以包含关于请求的信息，例如客户端支持的内容类型（Accept），或者发送的数据编码方式（Content-Type）。
• 在响应中，标头可以包含服务器返回的数据格式（如 Content-Type）以及其他元数据（如 Cache-Control）。

空行（Empty Line）

起始行和标头之间有一个空行，用来标示标头部分已结束，后续部分是消息的主体。这个空行并不包含任何内容，但它是协议中区分标头和正文的关键。

消息正文（Body）

• 消息的正文部分包含实际的数据，可能是请求中发送给服务器的数据（如表单内容或文件），也可能是响应中服务器返回的资源数据（如 HTML 页面、JSON 数据等）。
• 消息是否包含正文由起始行和 HTTP 标头共同决定。并非所有的请求和响应都必须包含正文，例如在 GET 请求中通常不包含正文，而响应的 204 No Content 也没有正文。

请求方法一览

GET 获取

功能：请求指定资源的表示形式。它应该是一个只读操作，用于从服务器获取数据。

请求体：不应包含请求体。GET 请求仅用于获取数据，不会对服务器状态进行更改。

幂等性：GET 请求是幂等的。

缓存：可以被缓存，特别是在有缓存控制头的情况下。

GET /users/12345 HTTP/1.1
Host: example.com

HEAD 获取响应头

功能：请求与 GET 请求相同的响应，但不返回响应体，只返回响应头部信息。

请求体：没有请求体，和 GET 请求一样，只是没有响应体部分。

使用场景：常用于获取资源的元数据（如文件大小、类型、最后修改时间等），或者用于检查某个资源是否存在（通过检查响应的状态码）。

HEAD /users/12345 HTTP/1.1
Host: example.com

POST 创建

功能：通常用于创建资源。

请求体：POST 请求通常包含请求体，带有要提交的数据（如表单数据或 JSON 数据）。

幂等性：POST 请求非幂等。

使用场景：创建资源、提交表单数据、触发操作（例如处理文件上传、执行服务器端任务）。

POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
{
  "name": "John",
  "email": "john@example.com"
}

PUT 全量更新

功能：替换指定的资源。

请求体：请求体通常包含替换的完整数据。

幂等性：PUT 请求是幂等的。

适用场景：替换或更新一个已有资源，例如更新用户信息、修改资源内容等。

PUT /users/12345 HTTP/1.1
Host: example.com
Content-Type: application/json
{
  "name": "John Doe",
  "email": "john.doe@example.com"
} 

PATCH 部分更新

功能：对资源进行部分更新，通常用于局部修改资源。与 PUT 不同，PUT 会替换资源，而 PATCH 仅修改部分字段。

请求体：请求体包含部分更新的数据。

幂等性：PATCH 是非幂等的。

适用场景：对资源进行部分修改（如更新用户的部分信息而不是整个资源）。

PATCH /users/12345 HTTP/1.1
Host: example.com
Content-Type: application/json
{
  "email": "new.email@example.com"
}

DELETE 删除

功能：删除指定的资源。

请求体：通常没有请求体，只有 URL 和请求头部。

幂等性：DELETE 请求是幂等的。

适用场景：删除资源，如删除用户、删除文件等。

DELETE /users/12345 HTTP/1.1
Host: example.com

CONNECT 代理

功能：建立一个到指定服务器的隧道，通常用于 代理服务器，例如 SSL（HTTPS）连接。它与 HTTP 的请求和响应模型不一样，主要用于建立连接通道。

请求体：没有请求体。

使用场景：通常在 HTTP 代理时使用，用于建立与服务器之间的隧道。

OPTIONS 预检

功能：请求目标资源支持的 HTTP 方法。

请求体：没有请求体。

使用场景：常用于跨域请求（CORS），以及测试服务器支持的 HTTP 方法。

TRACE 回环测试

功能：执行消息回环测试，回传收到的请求用于调试目的，帮助追踪请求在网络路径中的传输情况。

请求体：没有请求体。

使用场景：一般用于调试和诊断，查看请求是否在网络中被篡改。

CONNECT 方法

CONNECT 方法的作用是让代理服务器与目标服务器建立一个 TCP 隧道，在这个隧道内，客户端和目标服务器之间的通信是 完全加密的。代理服务器只是一个中介，帮助建立连接，但不会解密或干预数据。

比如，你想通过代理访问 https://example.com：

1. 客户端发起 CONNECT 请求：客户端向代理服务器发送 CONNECT 请求，要求与目标服务器建立加密隧道。请求格式如下：

CONNECT example.com:443 HTTP/1.1
Host: example.com

这个请求告诉代理服务器，它需要建立一个到 example.com（端口 443，HTTPS） 的连接。

2. 代理服务器建立隧道：代理服务器接收到 CONNECT 请求后，会尝试与 example.com:443 建立 TCP 连接。这个过程是客户端与代理服务器之间的网络连接。

3. 代理返回成功响应：一旦代理服务器与目标服务器成功建立连接，它会向客户端返回一个 200 Connection Established 响应，表示隧道已建立。

HTTP/1.1 200 Connection Established

4. 加密数据传输：代理服务器此时不再参与数据的内容，而是充当一个中介。客户端和目标服务器直接通过该隧道进行加密的通信。代理服务器只是转发数据包，不会解密或干预。

5. HTTPS 通信：客户端和 example.com 之间的 HTTPS 通信在这个隧道中完成。代理服务器在整个过程中无法查看请求的内容，因为数据是加密的。

OPTIONS方法

OPTIONS 方法本质上是查询服务器支持哪些操作的请求，而不是请求资源的数据，一般用于预检请求（通常用于 CORS，即跨域资源共享）或者用于查看服务器的配置。

CORS 预检请求流程

预检请求（OPTIONS）

在实际发送跨域请求（如 POST 或 PUT）之前，浏览器会自动发送一个 OPTIONS 请求，询问目标服务器是否允许当前的跨域请求。

假设你正在通过浏览器向 https://example.com 发送一个跨域 POST 请求：

OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: http://yourdomain.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

• Origin：发送请求的源（即你的域名）。
• Access-Control-Request-Method：浏览器计划发送的实际请求方法（如 POST）。
• Access-Control-Request-Headers：浏览器打算发送的自定义请求头（如 Content-Type）。

服务器响应

如果服务器允许这个请求，响应会类似于：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://yourdomain.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

• Access-Control-Allow-Origin：指定允许的来源，可以是一个具体的域名，也可以是 *（表示允许所有域名）。
• Access-Control-Allow-Methods：允许的 HTTP 方法（如 GET、POST、PUT）。
• Access-Control-Allow-Headers：允许的请求头（如 Content-Type）。

如果响应中包含适当的 CORS 头部，浏览器会继续发送实际的请求。如果响应不符合要求，浏览器会阻止跨域请求。

OPTIONS 方法的响应头字段

OPTIONS 请求的响应通常包含以下头部信息，表明服务器支持的操作和其他选项：

Allow 头部

• Allow 头部表示服务器支持的 HTTP 方法（例如 GET、POST、PUT、DELETE 等）。

CORS 相关头部

• Access-Control-Allow-Origin：指定哪些源可以访问资源。
• Access-Control-Allow-Methods：允许的 HTTP 方法。
• Access-Control-Allow-Headers：允许的请求头。

Allow: GET, POST, PUT, DELETE
Access-Control-Allow-Origin: http://yourdomain.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization

TRACE方法

基本流程

TRACE 请求的主要目的是诊断网络路径中的任何潜在问题。客户端向服务器发送 TRACE 请求，服务器返回原始请求内容（包括请求头部信息），供客户端进行检查。

发送 TRACE 请求

客户端发送 TRACE 请求时，只需指定目标资源和必要的请求头。请求的格式如下：

TRACE /path HTTP/1.1
Host: example.com

TRACE 请求的响应

服务器返回 TRACE 请求的原始内容（请求头和请求体），以确认客户端发送的请求未被篡改。例如，服务器返回的响应可能如下：

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 83

TRACE /path HTTP/1.1
Host: example.com
Connection: close
User-Agent: SomeClient/1.0

• Content-Type: message/http：返回内容的类型是 HTTP 消息体。
• 请求头回显：服务器将原始请求头（包括 Host、Connection、User-Agent 等）原封不动地返回给客户端。

使用场景

TRACE 方法通常用于以下几种情况：

诊断网络问题：TRACE 方法可用于诊断客户端与目标服务器之间的请求是否被中间代理服务器、网关等设备篡改。客户端可以用它来确认请求在传输过程中是否被更改。

例如，检查是否有代理服务器篡改了请求头中的 User-Agent 或 Authorization 等重要信息。

安全性测试：TRACE 方法可以帮助测试目标服务器是否对请求进行了不必要的修改，或者是否存在被篡改的风险。

例如，如果某个服务器不正确地返回请求头信息，可能暴露了敏感数据（如 Authorization 头部），这是一个潜在的安全漏洞。

不过，由于安全性和隐私问题，许多现代的 Web 服务器和应用程序默认会禁用 TRACE 方法，或限制对它的访问。

请求方法对比

参考

HTTP request methods - HTTP | MDN

HTTP messages - HTTP | MDN