HTTP相关返回值异常如何解决（上篇）

​

今天我们讲讲HTTP相关返回值异常如何解决（实例持续更新中）

HTTP介绍

HTTP（超文本传输协议，Hypertext Transfer Protocol）是用于在网络上进行数据交换的应用层协议。它是万维网（WWW）的基础，允许客户端（通常是网页浏览器）与服务器之间进行通信。以下是对 HTTP 的一些基本介绍：

1. 基本概念 请求-响应模型: HTTP 使用请求-响应模型。客户端发送请求，服务器处理请求并返回响应。 无状态协议: 每个请求都是独立的，服务器不会记住之前的请求状态。这种设计简化了服务器的实现，但可能需要其他机制（如 cookies）来管理会话状态。
2. 请求和响应请求:

请求行: 包含请求方法（如 GET、POST）、请求的 URL 和 HTTP 版本。

请求头: 提供有关客户端环境的信息（如 User-Agent、Accept 等）。

请求体: 仅在某些请求方法（如 POST）中使用，包含要发送的数据。

响应:

状态行: 包含 HTTP 版本、状态码（如 200、404、500）和状态描述。

响应头: 提供有关响应的信息（如 Content-Type、Content-Length 等）。

响应体: 包含实际传输的数据（如 HTML 文档、图像等）。

1. 常见的 HTTP 方法GET: 请求指定的资源，通常用于获取数据。(模组支持)
   POST: 向指定资源提交数据，通常用于创建或更新数据。(模组支持)
   PUT: 更新指定资源的内容。
   DELETE: 删除指定的资源。
   HEAD: 类似于 GET，但服务器只返回响应头，不返回响应体。
2. HTTP 状态码 HTTP 状态码用于表示请求的结果，分为五类：
   1xx: 信息性状态码（如 100 Continue）。
   2xx: 成功状态码（如 200 OK）。
   3xx: 重定向状态码（如 301 Moved Permanently）。
   4xx: 客户端错误状态码（如 404 Not Found）。
   5xx: 服务器错误状态码（如 500 Internal Server Error）。

**HTTP客户端错误状态码情况

案例分析以及如何解决**

一、1xx信息性状态码

这些状态码表示请求已被接收，继续处理请求。

100 Continue: 客户端应继续发送请求的剩余部分。

1.1 状态码100的含义：

HTTP 状态码 100 Continue 是一个信息性状态码，表示客户端应继续发送请求的剩余部分。它通常是在客户端发送一个包含 Expect: 100-continue 头的请求时，服务器响应的。

使用场景：

大文件上传: 当客户端要上传一个大文件时，它可以先发送一个请求头，询问服务器是否准备好接收文件。这时，服务器可以返回 100 Continue，表示可以继续上传文件。

节省带宽: 如果服务器无法处理请求，返回 100 Continue 可以避免客户端发送大量数据，从而节省带宽和资源。

具体工作流程：

客户端发送请求: 客户端发送一个带有 Expect: 100-continue 的请求头。 服务器响应: 如果服务器准备好接收请求，返回 100 Continue，指示客户端继续发送请求体。 如果服务器无法处理请求（例如，身份验证失败或请求格式不正确），则服务器可以直接返回相应的错误状态码（如 401 或 403），而不是 100 Continue。

101 Switching Protocols: 服务器已理解客户端的请求，并将其协议更改为客户端所请求的协议。

1.2 状态码101的含义：

HTTP 状态码 101 Switching Protocols 是一个信息性状态码，表示服务器已经理解了客户端的请求，并将协议更改为客户端所请求的协议。这通常用于在 HTTP 协议和其他协议之间进行切换，例如从 HTTP 协议切换到 WebSocket 协议。

使用场景

WebSocket 连接: 在建立 WebSocket 连接时，客户端首先发送一个 HTTP 请求，要求服务器将协议切换到 WebSocket。若服务器支持这一请求并同意切换，它会返回 101 状态码。

协议升级: 其他情况下，当客户端请求服务器使用不同的协议进行通信时（如从 HTTP/1.1 切换到 HTTP/2），也会用到此状态码。

具体工作流程

客户端发送请求: 客户端发送一个带有 Upgrade 头的请求，表明希望切换协议。

请求示例:

• GET /chat HTTP/1.1
• Host: example.com
• Upgrade: websocket
• Connection: Upgrade
• 服务器响应: 如果服务器支持请求的协议并同意切换，它会返回 101 Switching Protocols，表示协议已成功切换。

服务器响应示例:

• HTTP/1.1 101 Switching Protocols
• Upgrade: websocket
• Connection: Upgrade
• 后续通信: 协议切换后，客户端和服务器可以使用新协议进行后续通信。

二、2xx成功状态码

这些状态码表示请求已成功处理。

200 OK: 请求成功，通常返回请求的资源。

状态码200的含义：

HTTP 状态码 200 OK 是最常见的成功响应状态码，表示请求已成功处理。它通常用于标准的 GET 或 POST 请求，表明服务器已成功接收到请求并返回了所请求的资源。

使用场景

• GET 请求: 当客户端请求某个资源（如网页、图片等），并且服务器成功找到并返回该资源时，服务器会返回 200 OK。
• POST 请求: 当客户端向服务器提交数据（如表单数据）并且服务器成功处理这些数据时，也会返回 200 OK。此时，响应体可能包含操作结果的信息。

示例

​

201 Created: 请求成功并创建了新的资源。

状态码201的含义：

HTTP 状态码 201 Created 表示请求已成功处理，并且由于该请求，服务器创建了一个新的资源。这个状态码通常用于 POST 请求，特别是在客户端向服务器提交数据以创建新资源时。

使用场景

资源创建: 当客户端通过 POST 请求向服务器发送数据（例如，提交表单数据）并成功创建一个新资源时，服务器会返回 201 Created。

API 设计: 在 RESTful API 中，201 状态码常用于表示新资源的创建成功，并且通常在响应中包含指向该新资源的 URI。

示例

创建新资源的 POST 请求示例:

• POST /api/users HTTP/1.1
• Host: example.com
• Content-Type: application/json
• Content-Length: 45

{"name": "John Doe", "email": "[e-mail]"} 服务器响应示例:

• HTTP/1.1 201 Created
• Location: /api/users/123
• Content-Type: application/json

{"id": 123, "name": "John Doe", "email": "[e-mail]"}

关键要点

• Location 头: 通常在响应中包含 Location 头，指向新创建资源的 URI。
• 响应体: 可以在响应体中返回新资源的详细信息，帮助客户端确认创建结果。

202 Accepted: 请求已接受，但尚未处理。

状态码202的含义：

HTTP 状态码 202 Accepted 表示请求已被接受进行处理，但尚未完成。这意味着请求的处理是异步的，服务器已经接收到请求并将其放入处理队列中，但尚未提供最终结果。

使用场景

异步处理: 202 状态码通常用于那些需要较长时间才能完成的操作，例如上传大文件、复杂的数据处理或与外部服务的交互。

任务排队: 在某些情况下，服务器会返回 202 状态码以指示请求已被接受，但实际的处理将在后续时间内完成。

示例

异步请求的 POST 请求示例:

• POST /api/process-data HTTP/1.1
• Host: example.com
• Content-Type: application/json
• Content-Length: 50

{"data": "large dataset or task details"} 服务器响应示例:

• HTTP/1.1 202 Accepted
• Content-Type: application/json

{"message": "Your request is being processed"}

关键要点

请求已接受: 202 状态码表明请求已经被接受，而不是直接表示成功完成。 结果不可用: 由于处理是异步的，客户端通常需要通过其他机制（如轮询或回调）来获取处理结果。

203 Non-Authoritative Information: 服务器成功处理了请求，但返回的信息可能来自另一来源。

状态码203的含义：

HTTP 状态码 203 Non-Authoritative Information 表示请求已成功处理，但返回的信息可能不是来自原始服务器，而是来自一个代理服务器或其他中间实体。这意味着响应的内容可能经过了修改或附加了额外的信息。

使用场景

代理服务器: 当客户端通过代理服务器发送请求时，代理可能会返回 203 状态码以指示响应的内容不是来自原始服务器。

内容修改: 如果代理对响应进行了某种形式的修改，比如添加了额外的头信息，服务器可能会返回 203 状态码，告知客户端这部分信息可能不具有权威性。

示例

通过代理服务器的请求示例:

• GET /api/resource HTTP/1.1
• Host: example.com

代理服务器的响应示例:

• HTTP/1.1 203 Non-Authoritative Information
• Content-Type: application/json

{"data": "This data is modified or supplemented by the proxy"}

关键要点

非权威性信息: 203 状态码用于表示返回的信息可能不是最原始或权威的，客户端应谨慎对待这些信息。

不常用: 在实际应用中，203 状态码的使用相对较少，大多数情况下，客户端和服务器之间的直接通信更为常见。

204 No Content: 请求成功，但没有返回内容。

状态码204的含义：

HTTP 状态码 204 No Content 表示请求已成功处理，但没有内容返回。这通常用于处理成功的请求，但没有需要返回给客户端的实体内容。

使用场景

成功处理的请求: 当客户端发送请求（例如，DELETE 请求）并且服务器成功处理了该请求，但不需要返回任何内容时，可以使用 204 状态码。

更新操作: 在某些情况下，客户端可能发送更新请求（如 PUT），服务器成功处理后，可以返回 204 状态码而不返回任何数据。

保持连接: 204 状态码可以用于保持与客户端的连接，而不传送实际的数据内容。

示例

成功删除资源的 DELETE 请求示例:

• DELETE /api/resource/123 HTTP/1.1
• Host: example.com

服务器响应示例:

• HTTP/1.1 204 No Content

关键要点

无内容返回: 204 状态码明确表示没有返回的内容，客户端不应期望任何响应体。

保持连接: 由于没有内容，204 响应通常具有较小的负担和较快的处理速度，有助于提高性能。

205 Reset Content: 请求成功，要求客户端重置文档视图。

状态码205的含义：

HTTP 状态码 205 Reset Content 表示请求已成功处理，但客户端需要重置视图或输入字段。这通常用于表单提交后，服务器希望客户端清除或重置其当前的内容。

使用场景

表单处理: 当客户端提交表单后，服务器可能会返回 205 状态码，指示客户端重置表单输入内容，以便用户可以进行新的输入。

UI 状态重置: 在某些应用程序中，服务器可能希望客户端清除当前的视图状态或数据，以确保用户体验的一致性。

示例

表单提交的 POST 请求示例:

• POST /api/submit-form HTTP/1.1
• Host: example.com
• Content-Type: application/x-www-form-urlencoded

name=John&email=[e-mail] 服务器响应示例:

• HTTP/1.1 205 Reset Content

关键要点

重置内容: 205 状态码明确表示客户端应该重置其当前的内容或视图状态，通常与表单操作相关。

不返回内容: 和 204 状态码类似，205 响应通常不包含实体内容。

206 Partial Content: 服务器成功处理了部分 GET 请求，返回的是部分资源。

状态码206的含义：

HTTP 状态码 206 Partial Content 表示服务器成功处理了部分 GET 请求。这通常用于当客户端请求资源的某一部分时，服务器能够满足该请求并返回所请求的部分内容。

使用场景

范围请求: 客户端可能会使用 Range 请求头来请求资源的特定部分（例如，视频流、音频流或大型文件的下载）。服务器根据请求的范围返回相应的部分内容。

大文件下载: 当用户下载大文件时，支持恢复下载的客户端可以请求文件的特定字节范围，以便在网络中断时能够继续下载。

示例

范围请求的 GET 请求示例:

• GET /large-file.zip HTTP/1.1
• Host: example.com
• Range: bytes=0-499

服务器响应示例:

• HTTP/1.1 206 Partial Content
• Content-Range: bytes 0-499/123456
• Content-Length: 500
• Content-Type: application/zip

关键要点

部分内容: 206 状态码表示请求成功并返回的是请求的部分内容，而不是整个资源。

Content-Range 头: 响应中会包含 Content-Range 头，指示返回的内容范围和资源的总大小。

三、3xx重定向状态码

这些状态码表示客户端需要进一步操作才能完成请求。

300 Multiple Choices: 请求的资源有多种选择，客户端可以选择其中一个。

状态码300的含义：

HTTP 状态码 300 Multiple Choices 表示请求的资源可以有多种表示，客户端可以选择其中之一。这个状态码通常用于指示用户或应用程序有多个选项可供选择，并且服务器提供了这些选项的列表。

使用场景

资源重定向: 当请求的资源有多个可用版本（例如，不同语言的网页、不同格式的文件等），服务器会返回 300 状态码，指明可选的资源。

内容协商: 服务器可能根据请求头（如 Accept 或 Accept-Language）提供不同的响应选项，让客户端选择最合适的内容。

示例

请求的 GET 请求示例:

• GET /example HTTP/1.1
• Host: example.com

服务器响应示例:

• HTTP/1.1 300 Multiple Choices
• Content-Type: text/html

​

关键要点

• 选择性: 300 状态码表示客户端可以选择多个资源，通常伴随响应内容列出这些选项。
• 用户体验: 该状态码可以提升用户体验，让用户根据需要选择最适合的资源。

301 Moved Permanently: 请求的资源已被永久移动到新位置，返回的新 URI 在响应中提供。

状态码301的含义：

HTTP 状态码 301 Moved Permanently 表示请求的资源已经永久移动到一个新的 URI（统一资源标识符），并且所有未来的请求都应使用新的 URI。这个状态码通常用于网页重定向，告知搜索引擎和客户端该资源的更新位置。

使用场景

网站重构: 当网站的结构或域名发生变化时，可以使用 301 状态码来指向新的地址，从而确保用户和搜索引擎能够正确找到页面。

SEO 优化: 使用 301 重定向可以将旧页面的权重传递给新页面，有助于保持搜索引擎排名。

内容迁移: 当资源从一个位置移动到另一个位置，但希望保持用户和外部链接的有效性时，使用 301 重定向是一个合适的选择。

示例

请求的 GET 请求示例:

• GET /old-page HTTP/1.1
• Host: example.com

服务器响应示例:

• HTTP/1.1 301 Moved Permanently
• Location: https://example.com/new-page
• Content-Type: text/html

​

关键要点

• Location 头: 响应中包含 Location 头，指示新的 URI。客户端应使用该 URI 进行后续请求。
• 搜索引擎友好: 301 状态码告知搜索引擎该页面永久移动，搜索引擎会更新其索引以反映这一变化。

302 Found: 请求的资源临时移动到新位置，客户端应使用新 URI 继续请求。

状态码302的含义：

HTTP 状态码 302 Found 表示请求的资源临时被移动到另一个 URI。当客户端接收到这个状态码时，它应立即使用新的 URI 进行后续请求。这种状态码通常用于临时重定向，意味着原始 URI 仍然有效，未来的请求可能仍然会返回原始资源。

使用场景

临时重定向: 在需要临时更改资源位置时，例如网站维护或临时活动的页面，302 状态码是适合的选择。

用户登录流程: 在用户成功登录后，可以使用 302 状态码将用户重定向到他们请求的页面。

A/B 测试: 在进行 A/B 测试时，可以使用 302 状态码将用户临时重定向到不同的页面进行分析。

示例

请求的 GET 请求示例:

• GET /old-page HTTP/1.1
• Host: example.com

服务器响应示例:

• HTTP/1.1 302 Found
• Location: https://example.com/new-page
• Content-Type: text/html

​

关键要点

• Location 头: 响应中包含 Location 头，指示新的临时 URI。客户端应使用该 URI 进行后续请求。
• 缓存行为: 302 状态码通常不会被缓存，因为它表示临时重定向。

303 See Other: 对请求的响应可在不同 URI 处找到，客户端应使用 GET 方法请求该 URI。

状态码303的含义：

HTTP 状态码 303 See Other 表示客户端应使用 GET 方法请求另一个 URI 来获取所需的资源。它通常用于在处理 POST 请求后重定向客户端到一个新的页面。这一状态码的主要目的是确保客户端获取资源时使用的是正确的 HTTP 方法。

使用场景

表单提交: 在用户提交表单（例如，登录或注册）后，服务器可以返回 303 状态码，将用户重定向到一个结果页面，而不是重新提交表单。这有助于避免重复提交。

RESTful API: 在 RESTful 服务中，303 可以用于指示客户端在某个操作后应获取资源的不同位置。

状态更新: 在执行某些操作（如更新或删除）后，服务器可以使用 303 状态码引导客户端查看更新后的状态或结果。

示例

请求的 POST 请求示例:

• POST /submit-form HTTP/1.1
• Host: example.com
• Content-Type: application/x-www-form-urlencoded
• username=user&password=pass

服务器响应示例:

• HTTP/1.1 303 See Other
• Location: https://example.com/success
• Content-Type: text/html

​

关键要点

• Location 头 : 响应中包含 Location 头，指示新的 URI。客户端应使用 GET 方法请求该 URI。
• HTTP 方法 : 303 状态码确保客户端在重定向后使用 GET 方法，而不是继续使用原来的请求方法（如 POST）。

304 Not Modified: 客户端的缓存版本是最新的，服务器没有新内容。

状态码304的含义：

HTTP 状态码 304 Not Modified 表示所请求的资源自上次请求以来没有被修改。这通常与缓存机制相关，用于指示客户端可以使用其缓存的版本，而不需要重新下载资源。

使用场景 缓存优化: 当客户端向服务器请求资源时，它可能会发送一个条件请求，附带 If-Modified-Since 或 If-None-Match 头。如果资源在服务器上没有被修改，服务器会返回 304 状态码，从而节省带宽和提高加载速度。

减少延迟: 通过使用 304 状态码，服务器可以减少不必要的数据传输，提高性能。

示例

请求的 GET 请求示例:

• GET /image.png HTTP/1.1
• Host: example.com
• If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

服务器响应示例:

• HTTP/1.1 304 Not Modified

关键要点

• 条件请求: 304 状态码通常与条件请求一起使用，客户端会在请求中包含 If-Modified-Since 或 If-None-Match 头。
• 没有消息体: 在响应中，304 状态码通常不会包含消息体，因此不会传输任何资源数据。

305 Use Proxy: 请求的资源必须通过指定的代理访问。

状态码305的含义：

HTTP 状态码 305 Use Proxy 表示请求的资源必须通过指定的代理进行访问。此状态码的使用并不常见，且在某些情况下可能会造成安全隐患，因此在现代 web 开发中很少被使用。

使用场景

代理需求: 当服务器希望客户端通过特定的代理服务器来访问请求的资源时，可以使用 305 状态码。如果客户端没有配置该代理，则可能无法访问所请求的资源。 示例 请求的 GET 请求示例:

• GET /resource HTTP/1.1
• Host: example.com

服务器响应示例:

• HTTP/1.1 305 Use Proxy
• Location: http://proxy.example.com:8080/

在这个例子中，响应中的 Location 头指示客户端应该通过 http://proxy.example.com:8080/ 这个代理来访问所请求的资源。

关键要点

• 安全隐患: 由于 305 状态码可能会导致安全问题（例如，恶意代理），很多浏览器和 HTTP 客户端并不支持或忽略这一状态码。
• 不常用: 这个状态码在实际应用中并不常见，通常开发者会选择其他方法来实现类似的功能。

307 Temporary Redirect: 请求的资源临时移动到新位置，客户端应使用原来的请求方法继续请求。

状态码307的含义：

HTTP 状态码 307 Temporary Redirect 表示请求的资源临时移动到一个新的 URI。与 302 状态码类似，307 也用于临时重定向，但有一个重要的区别：307 确保客户端在重定向时使用原始的 HTTP 方法。

使用场景

保持方法一致性: 当客户端发起一个 POST 请求时，如果服务器返回 307 状态码，客户端在重定向到新 URI 时仍然使用 POST 方法。这在某些情况下非常重要，例如提交表单后需要临时重定向到不同的页面。

临时重定向: 用于指示资源临时移动到新位置，适用于需要在短期内更改资源位置的场景。

示例

请求的 POST 请求示例:

• POST /submit-form HTTP/1.1
• Host: example.com
• Content-Type: application/x-www-form-urlencoded
• data=value

服务器响应示例:

• HTTP/1.1 307 Temporary Redirect
• Location: http://example.com/thank-you

在这个例子中，客户端会被告知资源临时移动到 http://example.com/thank-you，并且仍然会使用 POST 方法进行请求。

关键要点

• 方法保持: 与 302 状态码不同，307 状态码要求客户端在重定向时保持原始的 HTTP 方法。
• 临时性: 307 状态码是临时的，表示将来可能会恢复到原始 URI。

308 Permanent Redirect: 请求的资源永久移动到新位置，客户端应使用原来的请求方法继续请求。

状态码303的含义：

HTTP 状态码 308 Permanent Redirect 表示请求的资源已被永久移动到一个新的 URI，并且客户端在重定向时应继续使用原始的 HTTP 方法（例如，POST、PUT等）。

使用场景

方法保持: 与 301 状态码不同，308 确保在重定向时客户端使用原始的 HTTP 方法。这对于某些操作（如文件上传或表单提交）非常重要。

永久性重定向: 用于指示资源永久性地移动到新的位置，适用于需要更新链接或资源地址的场景。

示例

请求的 POST 请求示例:

• POST /old-endpoint HTTP/1.1
• Host: example.com
• Content-Type: application/json

{"key": "value"}

服务器响应示例:

• HTTP/1.1 308 Permanent Redirect
• Location: http://example.com/new-endpoint

在这个例子中，客户端会被告知资源永久移动到 http://example.com/new-endpoint，并且在重定向时仍然使用 POST 方法进行请求。

关键要点

• 方法保持: 308 状态码确保客户端在重定向时保持原始的 HTTP 方法，这对于某些请求非常关键。
• 永久性: 308 表示请求的资源已被永久移动，客户端应更新其链接。

​