47、HTTP响应状态码详解

HTTP响应状态码详解

1. 常见客户端请求异常状态码

1.1 404和410状态码

当客户端请求的URI没有映射到任何资源时，会发送404（“Not Found”）和410（“Gone”）状态码。404用于服务器完全不知道客户端请求的是什么；410用于服务器知道该资源曾经存在，但现在已不存在。

1.2 409状态码

当客户端尝试执行一项操作，该操作会使一个或多个资源处于不一致状态时，会发送409（“Conflict”）状态码。

1.3 SOAP Web服务状态码

SOAP Web服务仅使用状态码200（“OK”）和500（“Internal Server Error”）。500状态码可能是由于发送给SOAP服务器的数据有问题、数据处理有问题或SOAP服务器本身存在内部问题。要了解请求发生了什么，不能仅查看响应的前三个字节，还必须解析包含描述性“错误”的SOAP文档主体。

2. 1xx系列状态码：元信息

1xx系列的响应状态码仅用于与HTTP服务器的协商。

2.1 100（“Continue”）

重要性：中等，但截至撰写本文时很少使用。这是对HTTP“三思而后行”（LBYL）请求的可能响应之一。此状态码表示客户端应重新发送其初始请求，包括第一次省略的（可能很大或敏感的）表示。客户端无需担心发送表示后被拒绝。对LBYL请求的另一个可能响应是417（“Expectation Failed”）。
- 操作步骤 ：要发出LBYL请求，客户端必须将 Expect 头设置为文字值“100-continue”，还必须设置服务器在决定是否以100或417响应时所需的任何其他头。

2.2 101（“Switching Protocols”）

重要性：非常低。只有当客户端的请求使用 Upgrade 头通知服务器，客户端更希望使用除HTTP之外的某种协议时，才会收到此响应码。响应码101表示“好的，现在我使用另一种协议”。通常，HTTP客户端在读取服务器的响应后会关闭TCP连接，但响应码101意味着客户端应停止作为HTTP客户端，开始作为其他类型的客户端。
- 操作步骤 ：
- 请求头 ：客户端将 Upgrade 设置为它更希望使用的协议列表。
- 响应头 ：如果服务器希望升级，它会发回一个 Upgrade 头，说明要切换到的协议，然后是一个空行。服务器不会关闭TCP连接，而是开始使用新协议进行通信，直到连接关闭。

下面是1xx系列状态码的简单表格总结：
| 状态码 | 名称 | 重要性 | 说明 |
| ---- | ---- | ---- | ---- |
| 100 | Continue | 中等 | 用于LBYL请求，指示客户端重新发送初始请求 |
| 101 | Switching Protocols | 非常低 | 客户端请求切换协议，服务器同意 |

3. 2xx系列状态码：成功

2xx错误状态码表示操作成功。

3.1 200（“OK”）

重要性：非常高。在大多数情况下，这是客户端希望看到的状态码。它表示服务器成功执行了客户端请求的任何操作，并且2xx系列中没有更具体的状态码适用。例如，当客户端请求书签列表时，书签服务会发送此状态码和相应的表示。
- 实体主体 ：对于GET请求，是客户端请求的资源的表示；对于其他请求，是所选资源的当前状态的表示或刚刚执行的操作的描述。

3.2 201（“Created”）

重要性：高。当服务器应客户端请求创建新资源时，会发送此状态码。例如，书签服务在响应创建新用户账户或书签的POST请求时会发送此状态码。
- 响应头 ： Location 头应包含新资源的规范URI。
- 实体主体 ：应描述并链接到新创建的资源。如果使用 Location 头告知客户端资源的实际位置，该资源的表示也是可以接受的。

3.3 202（“Accepted”）

重要性：中等。客户端的请求无法或不会实时处理，将在以后处理。请求看起来有效，但最终处理时可能会出现问题。当请求触发异步操作、现实世界中的操作或需要很长时间的操作，以至于让Web客户端等待没有意义时，这是一个合适的响应。
- 响应头 ：待处理的请求应作为资源公开，以便客户端稍后可以检查其状态。 Location 头可以包含此资源的URI。
- 实体主体 ：如果客户端无法稍后检查请求的状态，至少应给出请求将被处理的估计时间。

3.4 203（“Non - Authoritative Information”）

重要性：非常低。此状态码与200（“OK”）相同，但服务器希望客户端知道某些响应头不是来自服务器，它们可能是从客户端的先前请求中镜像过来的，或从第三方获取的。
- 响应头 ：客户端应知道某些头可能不准确，其他头可能在服务器不知道其含义的情况下被传递。

3.5 204（“No Content”）

重要性：高。此状态码通常在响应PUT、POST或DELETE请求时发送，此时服务器拒绝发送任何状态消息或表示。服务器也可能在GET请求时发送204：请求的资源存在，但表示为空。与304（“Not Modified”）比较。204常用于Ajax应用程序，它让服务器告诉客户端其输入已被接受，但客户端不应更改任何UI元素。
- 实体主体 ：不允许有实体主体。

3.6 205（“Reset Content”）

重要性：低。与204（“No Content”）类似，但它意味着客户端应重置作为数据来源的视图或数据结构。例如，在Web浏览器中提交HTML表单，如果响应是204（“No Content”），表单中的数据会保留，可继续修改；如果是205，表单字段会重置为原始值。
- 实体主体 ：不允许有实体主体。

3.7 206（“Partial Content”）

重要性：对于支持部分GET的服务非常高，否则较低。此状态码与200（“OK”）类似，但它是对部分GET请求的响应，即使用 Content - Range 请求头的请求。客户端通常会发出部分GET请求以恢复大二进制表示的中断下载。
- 请求头 ：客户端发送 Content - Range 头的值。
- 响应头 ： Date 头是必需的。 ETag 和 Content - Location 头应设置为与整个表示一起发送时相同的值。如果实体主体是表示的单个字节范围，整个响应必须有一个 Content - Range 头，说明正在提供表示的哪些字节；如果主体是多部分实体（即提供表示的多个字节范围），每个部分必须有自己的 Content - Range 头。
- 实体主体 ：不会包含完整的表示，只是表示中的一个或多个字节序列。

3.8 207（“Multi - Status”）

重要性：低到中等。这是HTTP标准的WebDAV扩展，用于批量请求的响应。当一个请求对多个资源进行操作时，某些操作可能成功，而其他操作可能失败，单个响应码不足以传达请求的状态。此响应码告诉客户端在实体主体中查找HTTP状态码列表，每个状态码对应批量请求中的一个操作。
- 实体主体 ：应包含一个使用WebDAV词汇表描述多个HTTP响应的XML文档。

下面是2xx系列状态码的流程图：

graph LR
    A[请求] -->|成功| B{状态码判断}
    B -->|200| C(OK)
    B -->|201| D(Created)
    B -->|202| E(Accepted)
    B -->|203| F(Non - Authoritative Information)
    B -->|204| G(No Content)
    B -->|205| H(Reset Content)
    B -->|206| I(Partial Content)
    B -->|207| J(Multi - Status)

3. 3xx系列状态码：重定向

3xx状态码表示客户端需要做一些额外的工作才能得到它想要的东西。它们最常用于GET请求，通常告诉客户端只能通过向另一个URI发送第二个GET请求来获取所需的表示。这个二级URI会在 Location 响应头中发送。

3.1 300（“Multiple Choices”）

重要性：低。当服务器有请求资源的多个表示，且不知道客户端想要哪个表示时，可以发送此状态码。可能是客户端没有使用 Accept - * 头指定表示，或者请求了不存在的表示。在这种情况下，服务器可以选择其首选表示，并发送200（“OK”）状态码，也可以发送300状态码和不同表示的可能URI列表。
- 响应头 ：如果服务器有首选表示，可以将该表示的URI放在 Location 中。与其他3xx状态码一样，客户端可能会自动跟随 Location 中的URI。
- 实体主体 ：表示的URI列表，带有必要的信息，以便用户在它们之间做出选择。XHTML链接列表是一种很好的格式。

3.2 301（“Moved Permanently”）

重要性：中等。服务器知道客户端试图访问的资源，但不喜欢客户端用于请求该资源的URI。它希望客户端记录新的URI，并在未来的请求中使用。可以使用此状态码在URI更改时防止旧URI失效。
- 响应头 ：服务器应将规范URI放在 Location 中。
- 实体主体 ：服务器应发送一个带有指向新位置超链接的简短XHTML文件，但不是必需的。

3.3 302（“Found”）

重要性：了解此状态码非常重要，尤其是在编写客户端时，但不建议使用。此状态码是大多数重定向相关混淆的最终来源。它本应像307（“Temporary Redirect”）一样处理，实际上在HTTP 1.0中它的名称是“Moved Temporarily”。不幸的是，在现实中，大多数客户端将302像303（“See Other”）一样处理。区别在于客户端在收到对PUT、POST或DELETE请求的302响应时应该做什么。为了解决这种歧义，在HTTP 1.1中此响应码被重命名为“Found”，并创建了响应码307。此响应码仍被广泛使用，但具有歧义，建议服务发送303和307代替，除非确定是在处理不理解303或307的HTTP 1.0客户端。
- 响应头 ： Location 头包含客户端应重新提交请求的URI。
- 实体主体 ：应包含一个链接到新URI的超文本文档，与301相同。

3.4 303（“See Other”）

重要性：高。请求已被处理，但服务器不发送响应文档，而是向客户端发送响应文档的URI。这可能是静态状态消息的URI，或更有趣资源的URI。在后者的情况下，303是服务器发送资源表示而不强制客户端下载所有数据的一种方式。客户端预计会向 Location 的值发送GET请求，但不是必须的。303状态码是规范资源的好方法，可以通过多个URI提供资源，但每个表示只有一个“真实”的URI，其他所有URI使用303指向该表示的规范URI。
- 响应头 ： Location 头包含表示的URI。
- 实体主体 ：应包含一个链接到新URI的超文本文档，与301相同。

3.5 304（“Not Modified”）

重要性：高。此状态码与204（“No Content”）类似，响应主体必须为空。但204用于没有要发送的主体数据，304用于有数据但客户端已经拥有，再次发送没有意义。此状态码与条件HTTP请求一起使用。如果客户端发送带有日期（如周日）的 If - Modified - Since 头，且表示自周日以来没有更改，则304是合适的。发送200（“OK”）也是合适的，但再次发送表示会浪费带宽，因为客户端已经有该表示。
- 响应头 ： Date 头是必需的。 ETag 和 Content - Location 头应设置为如果响应码为200（“OK”）时会发送的相同值。如果缓存头 Expires 、 Cache - Control 和 Vary 与之前发送的不同，则是必需的。服务器可以发送更新的头而不发送新的主体，这在表示的元数据已更改但表示本身未更改时很有用。
- 实体主体 ：不允许有实体主体。

3.6 305（“Use Proxy”）

重要性：低。此状态码用于告诉客户端应重复其请求，但通过HTTP代理而不是直接访问服务器。此代码很少使用，因为服务器很少关心客户端使用特定的代理。如果存在基于代理的镜像站点，此代码会更频繁使用。如今，镜像站点为 http://www.example.com/ 提供相同的内容，但使用不同的URI，如 http://www.example.com.mysite.com/ ，原始站点可能使用307（“Temporary Redirect”）状态码将客户端发送到合适的镜像站点。如果存在基于代理的镜像站点，客户端将使用与原始相同的URI（ http://www.example.com/ ）访问镜像，但将 http://proxy.mysite.com/ 设置为代理，原始的 example.com 可能使用305状态码将客户端路由到地理位置接近的镜像代理。Web浏览器通常不能正确处理此状态码，这也是它不受欢迎的另一个原因。
- 响应头 ： Location 头包含代理的URI。

3.7 306：未使用

重要性：无。306状态码从未进入HTTP标准。它在互联网草案“HTTP/1.1 305 and 306 Response Codes”中被描述为“Switch Proxy”，是代理服务器发送的，用于让客户端开始使用不同的代理，无需关注。

3.8 307（“Temporary Redirect”）

重要性：高。请求未被处理，因为请求的资源不在原地，而是位于另一个URI。客户端应向另一个URI重新提交请求。对于GET请求，当只请求服务器发送表示时，此状态码与303（“See Other”）相同。例如，服务器希望将客户端发送到镜像站点时，307是对GET请求的合适响应。但对于POST、PUT和DELETE请求，当服务器预计对请求采取某些行动时，此状态码与303有很大不同。对POST、PUT或DELETE请求的303响应意味着操作已成功，但响应实体主体不会随此请求发送，如果客户端想要响应实体主体，需要向另一个URI发送GET请求；对POST、PUT或DELETE请求的307响应意味着服务器甚至没有尝试执行该操作，客户端需要向 Location 头中的URI重新提交整个请求。
- 响应头 ： Location 头包含客户端应重新提交请求的URI。
- 实体主体 ：应包含一个链接到新URI的超文本文档，与301相同。

下面是3xx系列状态码的表格总结：
| 状态码 | 名称 | 重要性 | 说明 |
| ---- | ---- | ---- | ---- |
| 300 | Multiple Choices | 低 | 服务器有多个表示，不知客户端需求 |
| 301 | Moved Permanently | 中等 | 资源永久移动 |
| 302 | Found | 需了解 | 易混淆，建议用303和307代替 |
| 303 | See Other | 高 | 发送响应文档的URI |
| 304 | Not Modified | 高 | 数据未更改，无需重发 |
| 305 | Use Proxy | 低 | 让客户端通过代理请求 |
| 306 | 未使用 | 无 | 未进入标准 |
| 307 | Temporary Redirect | 高 | 资源临时重定向 |

4. 4xx系列状态码：客户端错误

这些状态码表示客户端方面存在问题，可能是认证问题、表示格式问题或HTTP库本身的问题。客户端需要在其端修复某些问题。

4.1 400（“Bad Request”）

虽然原文未提及，但在常见的HTTP状态码体系中，400 状态码较为常见。它表示客户端发送的请求有错误，比如请求参数格式错误、缺少必要参数等。服务器无法理解该请求，客户端需要修正请求后重新发送。

4.2 401（“Unauthorized”）

此状态码表示请求需要用户进行身份验证。当客户端访问需要授权的资源，但未提供有效的身份凭证时，服务器会返回 401 状态码。客户端需要提供正确的用户名和密码等认证信息，再次发起请求。

4.3 403（“Forbidden”）

与 401 不同，403 表示客户端已经通过身份验证，但没有权限访问请求的资源。即使提供了正确的认证信息，服务器也拒绝了请求。这可能是因为用户没有足够的权限、资源被限制访问等原因。

4.4 404（“Not Found”）和 410（“Gone”）

当客户端请求的 URI 没有映射到任何资源时，会发送这两个状态码。404 用于服务器完全不知道客户端请求的是什么；410 用于服务器知道该资源曾经存在，但现在已不存在。例如，当用户访问一个已经被删除的网页时，可能会收到 410 状态码；而访问一个根本不存在的页面时，通常会收到 404 状态码。

4.5 409（“Conflict”）

当客户端尝试执行一项操作，该操作会使一个或多个资源处于不一致状态时，会发送 409 状态码。比如在多用户同时对同一资源进行修改时，可能会导致资源状态冲突，服务器就会返回 409 状态码。

下面是 4xx 系列状态码的简单表格总结：
| 状态码 | 名称 | 说明 |
| ---- | ---- | ---- |
| 400 | Bad Request | 客户端请求有错误，需修正请求 |
| 401 | Unauthorized | 请求需要身份验证 |
| 403 | Forbidden | 已认证但无权限访问资源 |
| 404 | Not Found | 服务器不知请求的资源 |
| 410 | Gone | 资源曾经存在，现在已不存在 |
| 409 | Conflict | 操作会使资源处于不一致状态 |

4.6 4xx 系列状态码处理建议

当客户端收到 4xx 系列状态码时，可以按照以下步骤进行处理：
1. 400 状态码 ：检查请求参数的格式和内容，确保所有必要参数都已提供且格式正确。可以查看服务器返回的错误信息，根据提示修正请求。
2. 401 状态码 ：提供有效的身份凭证，如用户名和密码。可以通过 HTTP 基本认证、OAuth 等方式进行身份验证。
3. 403 状态码 ：确认用户是否具有访问该资源的权限。如果没有权限，可以联系管理员申请权限。
4. 404 状态码 ：检查请求的 URI 是否正确。如果是用户输入错误，可以提示用户修正 URI；如果是资源确实不存在，可以提供相关的替代资源或错误提示。
5. 410 状态码 ：告知用户该资源已不存在，可以提供相关的历史信息或替代资源。
6. 409 状态码 ：检查请求操作是否会导致资源冲突。可以通过加锁、版本控制等方式避免冲突，或者在发生冲突时提供相应的解决方案。

下面是 4xx 系列状态码处理的流程图：

graph LR
    A[收到 4xx 状态码] --> B{状态码判断}
    B -->|400| C(检查请求参数，修正请求)
    B -->|401| D(提供有效身份凭证)
    B -->|403| E(确认权限，联系管理员)
    B -->|404| F(检查 URI，提供替代资源)
    B -->|410| G(告知资源不存在，提供历史信息)
    B -->|409| H(检查操作，避免冲突)

总结

HTTP 响应状态码是客户端和服务器之间通信的重要组成部分，不同的状态码代表了不同的请求结果和处理情况。了解这些状态码的含义和使用场景，对于开发人员编写高效、稳定的 Web 应用程序至关重要。

1xx 系列状态码主要用于与服务器的协商，如 100 状态码用于“三思而后行”请求，101 状态码用于协议切换。
2xx 系列状态码表示操作成功，不同的状态码有不同的具体含义，如 200 表示请求成功，201 表示创建新资源等。
3xx 系列状态码用于重定向，客户端需要根据 Location 头的信息重新发送请求。其中 301 表示永久重定向，302 和 307 表示临时重定向，303 用于发送响应文档的 URI。
4xx 系列状态码表示客户端错误，客户端需要检查自身请求的问题并进行修正。常见的有 400、401、403、404、410 和 409 等状态码。

在实际开发中，开发人员应该根据不同的状态码采取相应的处理措施，以提高用户体验和应用程序的稳定性。同时，要注意避免使用容易引起混淆的状态码，如 302 状态码，尽量使用更明确的 303 和 307 状态码。