HTTP 响应代码总结

HTTP 响应状态代码指示特定 HTTP 请求是否已成功完成。响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)。状态代码由section 10 of RFC 2616定义。

接下来按照上述五种分类分别展开如下：

1. 信息响应

该分类下包含的响应代码分别为：100(continue), 101(Swtiching Protocol), 102(Processing), 103(Early Hints)。

1.1. 100 Continue

这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。

HTTP 100 Continue 信息型状态响应码表示目前为止一切正常，客户端应该继续请求，如果已完成请求则忽略。

为了让服务器检查请求的首部，客户端必须在发送请求实体前，在初始化请求中发送 Expect: 100-continue 首部并接收 100 Continue 响应状态码。

1.1.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

1.1.2. 浏览器兼容性

在http/status.json中没有发现兼容性数据（No compatibility data found for http/status.json.）。

继续在这页检查问题，或者向 mdn/browser-compat-data 贡献缺失的数据（Check for problems with this page or contribute missing data to mdn/browser-compat-data.）。

1.2. 101 Switching Protocol

该代码是响应客户端的 Upgrade (en-US) 标头发送的，并且指示服务器也正在切换的协议。

HTTP 101 Switching Protocol（协议切换）状态码表示服务器应客户端升级协议的请求（Upgrade (en-US)请求头）正在切换协议。

服务器会发送一个Upgrade (en-US)响应头来表明其正在切换过去的协议。
该过程在协议升级机制(Protocol upgrade mechanism)中详细描述。

1.2.1. 示例

在使用 WebSockets 时会用到协议切换。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

1.2.2. 相关协议

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

1.3. 102 Processing (WebDAV <en_US>)

此代码表示服务器已收到并正在处理该请求，但没有响应可用。

WebDAV（Web Distributed Authoring and Versioning）是一个HTTP的扩展，其可以使web开发者从客户端远程更新服务器上的内容（WebDAV (Web Distributed Authoring and Versioning) is an HTTP Extension that lets web developers update their content remotely from a client.）。

WebDAV很少被单独使用，但另外两个拓展则很常见：CalDAV (remote-access calendar) 以及CardDAV (remote-access address book)（WebDAV is rarely used alone, but two extensions are very common: CalDAV (remote-access calendar) and CardDAV (remote-access address book).）。

WebDAV允许客户端做如下操作：

• 添加、删除以及提取web页面的元数据信息（比如作者和创建日期）
• 可以将页面链接到任意相关媒体类型的页面上
• 创建文档集合并且提取分级列表
• 拷贝以及移动web页面
• 将同一时间超过1个人编辑的文档加锁

WebDAV allows clients to

• add, delete, and retrieve webpage metadata (e.g. author or creation date)
• link pages of any media type to related pages
• create sets of documents and retrieve hierarchical list
• copy and move webpages
• lock a document from being edited by more than one person at a time

更详细信息参见WebDAV

1.4. 103 Early Hints

此状态代码主要用于与Link 链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源。

参考文档： An HTTP Status Code for Indicating Hints

2. 成功响应

该响应状态代码下面包含的代码分别为：200 OK, 201 Created, 202 Accepted, 203 Non-Authoritative Information, 204 No Content, 205 Reset Content, 206 Partial Content, 207 Multi-Status (WebDAV (en-US)), 208 Already Reported (WebDAV (en-US)), 226 IM Used (HTTP Delta encoding)。

分别展开如下。

2.1. 200 OK

请求成功。成功的含义取决于HTTP方法：

• GET：资源已被提取并在消息正文中传输。
• HEAD：实体标头位于消息正文中。
• POST：描述动作结果的资源在消息体中传输。
• TRACE：消息正文包含服务器收到的请求消息

2.1.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.1.2. 浏览器兼容性

2.2. 201 Created

该请求已成功，并因此创建了一个新的资源。这通常是在POST请求，或是某些PUT请求之后返回的响应。

在HTTP协议中，201 Created 是一个代表成功的应答状态码，表示请求已经被成功处理，并且创建了新的资源。新的资源在应答返回之前已经被创建。同时新增的资源会在应答消息体中返回，其地址或者是原始请求的路径，或者是Location首部的值。

这个状态码的常规使用场景是作为 POST 请求的返回值。

2.2.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.2.2. 浏览器兼容性

2.3. 202 Accepted

请求已经接收到，但还未响应，没有结果。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。

响应状态码 202 Accepted 表示服务器端已经收到请求消息，但是尚未进行处理。但是对于请求的处理确实无保证的，即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理，或者是对请求进行批处理的情形。

2.3.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.4. 203 Non-Authoritative Information

服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。

HTTP 204 No Content 成功状态响应码，表示该请求已经成功了，但是客户端客户不需要离开当前页面。默认情况下 204 响应是可缓存的。一个 ETag 标头包含在此类响应中。

使用惯例是，在 PUT 请求中进行资源更新，但是不需要改变当前展示给用户的页面，那么返回 204 No Content。如果创建了资源，则返回 201 Created 。如果应将页面更改为新更新的页面，则应改用 200 。

2.4.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.4.2. 浏览器兼容性

2.5. 204 No Content

服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。

HTTP 204 No Content 成功状态响应码，表示该请求已经成功了，但是客户端客户不需要离开当前页面。默认情况下 204 响应是可缓存的。一个 ETag 标头包含在此类响应中。

使用惯例是，在 PUT 请求中进行资源更新，但是不需要改变当前展示给用户的页面，那么返回 204 No Content。如果创建了资源，则返回 201 Created 。如果应将页面更改为新更新的页面，则应改用 200 。

2.5.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.5.2. 浏览器兼容性

2.6. 205 Reset Content

服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。

在 HTTP 协议中，响应状态码 205 Reset Content 用来通知客户端重置文档视图，比如清空表单内容、重置 canvas 状态或者刷新用户界面。

2.6.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

2.7. 206 Partial Content

服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。

HTTP 206 Partial Content 成功状态响应代码表示请求已成功，并且主体包含所请求的数据区间，该数据区间是在请求的 Range 首部指定的。

如果只包含一个数据区间，那么整个响应的 Content-Type 首部的值为所请求的文件的类型，同时包含 Content-Range 首部。

如果包含多个数据区间，那么整个响应的 Content-Type 首部的值为 multipart/byteranges ，其中一个片段对应一个数据区间，并提供 Content-Range 和 Content-Type 描述信息。

2.7.1. 示例

只包含一个数据区间的响应：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

… 26012 bytes of partial image data …

包含多个数据区间的响应：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String_separator

–String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

…the first range…
–String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

…the second range
–String_separator–

2.7.2. 规范

Hypertext Transfer Protocol (HTTP/1.1): Range Requests

2.7.3. 浏览器兼容性

2.8. 207 Multi-Status (WebDAV (en-US))

由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

2.9. 208 Already Reported (WebDAV (en-US))

在 DAV 里面使用: propstat 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。

2.10. 226 IM Used (HTTP Delta encoding)

服务器已经完成了对资源的 GET 请求，并且响应是对当前实例应用的一个或多个实例操作结果的表示。

3. 重定向

该部分包含的响应代码分别如下：

3.1. 300 Multiple Choice

被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。

300 Multiple Choices 是一个用来表示重定向的响应状态码，表示该请求拥有多种可能的响应。用户代理或者用户自身应该从中选择一个。由于没有如何进行选择的标准方法，这个状态码极少使用。

假如服务器可以提供一个优先选择，那么它应该生成一个 Location 首部。

3.1.1. 示例

参考这个页面： w3.org page for a Multiple Choice response

3.1.2. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

3.2. 301 Moved Permanently

被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。

HTTP 301 永久重定向 说明请求的资源已经被移动到了由 Location 头部指定的url上，是固定的不会再改变。搜索引擎会根据该响应修正。

尽管标准要求浏览器在收到该响应并进行重定向时不应该修改http method和body，但是有一些浏览器可能会有问题。所以最好是在应对GET 或 HEAD 方法时使用301，其他情况使用308 来替代301。

3.2.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

3.2.2. 浏览器兼容性

3.3. 302 Found

请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

HTTP 302 Found 重定向状态码表明请求的资源被暂时的移动到了由Location 头部指定的 URL 上。浏览器会重定向到这个URL， 但是搜索引擎不会对该资源的链接进行更新 (In SEO-speak, it is said that the link-juice is not sent to the new URL)。

即使规范要求浏览器在重定向时保证请求方法和请求主体不变，但并不是所有的用户代理都会遵循这一点，你依然可以看到有缺陷的软件的存在。所以推荐仅在响应 GET 或 HEAD 方法时采用 302 状态码，而在其他时候使用 307 Temporary Redirect 来替代，因为在这些场景下方法变换是明确禁止的。

在确实需要将重定向请求的方法转换为 GET的场景下，可以使用 303 See Other。例如在使用 PUT 方法进行文件上传操作时，需要返回确认信息（例如“你已经成功上传了xyz”）而不是上传的资源本身，就可以使用这个状态码。

3.3.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

3.3.2. 浏览器兼容性

3.4. 303 See Other

对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。

HTTP 303 See Other 重定向状态码，通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。

3.4.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

3.4.2. 浏览器兼容性

3.5. 304 Not Modified

如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304 响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。

HTTP 304 未改变说明无需再次传输请求的内容，也就是说可以使用缓存的内容。这通常是在一些安全的方法（safe），例如GET 或HEAD 或在请求中附带了头部信息：If-None-Match 或If-Modified-Since。

如果是 200 OK ，响应会带有头部 Cache-Control, Content-Location, Date, ETag, Expires，和 Vary。

很多浏览器的 开发者工具 会发出额外的请求，以达到 304 的目的，这样可以把资源以本地缓存的形式展现给开发者。

3.5.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

3.5.2. 浏览器兼容性

3.6. 305 Use Proxy

被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。

3.7. 306 unused

在最新版的规范中，306 状态码已经不再被使用。

3.8. 307 Temporary Redirect

请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

HTTP 307 Temporary Redirect，临时重定向响应状态码，表示请求的资源暂时地被移动到了响应的 Location 首部所指向的 URL 上。

原始请求中的请求方法和消息主体会在重定向请求中被重用。在确实需要将重定向请求的方法转换为 GET 的场景下，可以考虑使用 303 See Other 状态码。例如，在使用 PUT 方法进行文件上传操作时，如果需要返回一条确认信息（例如“你已经成功上传了 XYZ”），而不是返回上传的资源本身，就可以使用这个状态码。

状态码 307 与 302 之间的唯一区别在于，当发送重定向请求的时候，307 状态码可以确保请求方法和消息主体不会发生变化。如果使用 302 响应状态码，一些旧客户端会错误地将请求方法转换为 GET：也就是说，在 Web 中，如果使用了 GET 以外的请求方法，且返回了 302 状态码，则重定向后的请求方法是不可预测的；但如果使用 307 状态码，之后的请求方法就是可预测的。对于 GET 请求来说，两种情况没有区别。

3.8.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

3.8.2. 浏览器兼容性

3.9. 308 Permanent Redirect

这意味着资源现在永久位于由 Location: HTTP Response 标头指定的另一个 URI。 这与 301 Moved Permanently HTTP 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 POST，则必须在第二个请求中使用 POST。

在 HTTP 协议中， 308 Permanent Redirect（永久重定向）是表示重定向的响应状态码，说明请求的资源已经被永久的移动到了由 Location 首部指定的 URL 上。浏览器会进行重定向，同时搜索引擎也会更新其链接（用 SEO 的行话来说，意思是“链接汁”（link juice）被传递到了新的 URL）。

在重定向过程中，请求方法和消息主体不会发生改变，然而在返回 301 状态码的情况下，请求方法有时候会被客户端错误地修改为 GET 方法。

一些 Web 应用可能会将 308 Permanent Redirect 以一种非标准的方式使用以及用作其他用途。例如，Google Drive 会使用 308 Resume Incomplete 状态码来告知客户端文件上传终止且不完整。

3.9.1. 规范

The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)

3.9.2. 浏览器兼容性

4. 客户端相应

该部分响应状态代码分别如下：

4.1. 400 Bad Request

HTTP 400 Bad Request 响应状态码表示由于语法无效，服务器无法理解该请求。 客户端不应该在未经修改的情况下重复此请求。

1. 语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
2. 请求参数有误。

4.1.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

4.2. 401 Unauthorized

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。

状态码 401 Unauthorized 代表客户端错误，指的是由于缺乏目标资源要求的身份验证凭证，发送的请求未得到满足。

这个状态码会与 WWW-Authenticate 首部一起发送，其中包含有如何进行验证的信息。

这个状态类似于 403， 但是在该情况下，依然可以进行身份验证。

4.2.1. 示例

HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm=“Access to staging site”

4.2.2. 规范

HTTP/1.1: Authentication

4.2.3. 浏览器兼容性

4.3. 402 Payment Required

此响应码保留以便将来使用，创造此响应码的最初目的是用于数字支付系统，然而现在并未使用。

4.4. 403 Forbidden

服务器已经理解请求，但是拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应，假如它不希望让客户端获得任何信息。

状态码 403 Forbidden 代表客户端错误，指的是服务器端有能力处理该请求，但是拒绝授权访问。

这个状态类似于 401，但进入该状态后不能再继续进行验证。该访问是长期禁止的，并且与应用逻辑密切相关（例如不正确的密码）。

4.4.1. 示例

HTTP/1.1 403 Forbidden
Date: Wed, 21 Oct 2015 07:28:00 GMT

4.4.2. 规范

HTTP/1.1: Semantics and Content

4.4.3. 浏览器兼容性

4.5. 404 Not Found

请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

状态码 404 Not Found 代表客户端错误，指的是服务器端无法找到所请求的资源。返回该响应的链接通常称为坏链（broken link）或死链（dead link），它们会导向链接出错处理(link rot)页面。

404 状态码并不能说明请求的资源是临时还是永久丢失。如果服务器知道该资源是永久丢失，那么应该返回 410 (Gone) 而不是 404 。

4.5.1. 自定义错误页面

许多网站会将 404 页面的外观进行定制，使其对用户更友好，以及提供一些引导。例如，Apache 服务器可以在 .htaccess 文件中进行配置，代码片段如下：

ErrorDocument 404 /notfound.html

你可以访问一下 MDN 的 404 页面获取一些启发。

自定义的404页面应该是对用户友好且可读性高的，不能使用户产生困惑。

4.5.2. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

4.5.3. 浏览器兼容性

4.6. 405 Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。

状态码 405 Method Not Allowed 表明服务器禁止了使用当前 HTTP 方法的请求。

4.6.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

4.7. 406 Not Acceptable

请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。

HTTP 协议中的 406 Not Acceptable 状态码表示客户端错误，指代服务器端无法提供与 Accept-Charset 以及 Accept-Language 消息头指定的值相匹配的响应。

在实际应用中，这个错误状态码极少使用：不是给用户返回一个晦涩难懂（且难以更正）的错误状态码，而是将相关的消息头忽略，同时给用户提供一个看得见摸得着的页面。这种做法基于这样一个假设：即便是不能达到用户十分满意，也强于返回错误状态码。

如果服务器返回了这个错误状态码，那么消息体中应该包含所能提供的资源表现形式的列表，允许用户手动进行选择。

4.7.1. 规范

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

4.7.2. 浏览器兼容性

4.8. 407 Proxy Authentication Required

与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。

状态码 407 Proxy Authentication Required 代表客户端错误，指的是由于缺乏位于浏览器与可以访问所请求资源的服务器之间的代理服务器（proxy server ）要求的身份验证凭证，发送的请求尚未得到满足。

这个状态码会与 Proxy-Authenticate 首部一起发送，其中包含有如何进行验证的信息。

4.8.1. 示例

HTTP/1.1 407 Proxy Authentication Required
Date: Wed, 21 Oct 2015 07:28:00 GMT
Proxy-Authenticate: Basic realm=“Access to internal site”

4.8.2. 规范

HTTP/1.1: Authentication

4.8.3. 浏览器兼容性

4.9. 408 Request Timeout

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

响应状态码 408 Request Timeout 表示服务器想要将没有在使用的连接关闭。一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下。

服务器应该在此类响应中将 Connection 首部的值设置为 “close”，因为 408 意味着服务器已经决定将连接关闭，而不是继续等待。

这类响应出现的比较频繁，源于一些浏览器——例如 Chrome, Firefox 27+, 或者 IE9 等——使用 HTTP 协议中的预连接机制来加速上网体验。同时应该注意到，某些服务器会直接关闭连接，而不发送此类消息。

4.9.1. 规范

RFC 7231, section 6.5.7: 408 Request Timeout

4.10. 409 Conflict

由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。

响应状态码 409 Conflict 表示请求与服务器端目标资源的当前状态相冲突。

冲突最有可能发生在对 PUT 请求的响应中。例如，当上传文件的版本比服务器上已存在的要旧，从而导致版本冲突的时候，那么就有可能收到状态码为 409 的响应。

4.10.1. 规范

RFC 7231, section 6.5.8: 409 Conflict

4.11. 410 Gone

被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用 404 状态码。除非额外说明，否则这个响应是可缓存的。

HTTP 410 丢失 说明请求的目标资源在原服务器上不存在了，并且是永久性的丢失。如果不清楚是否为永久或临时的丢失，应该使用404。

410 响应默认会被缓存

4.11.1. 规范

RFC 7231, section 6.5.9: 410 Gone

4.11.2. 浏览器兼容性

在http/status中并没有发现兼容性数据（No compatibility data found for http/status.）
继续在这页检查问题或者向 mdn/browser-compat-data 提交缺失的数据（Check for problems with this page or contribute missing data to mdn/browser-compat-data.）

4.12. 411 Length Required

服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。

响应状态码 411 Length Required 属于客户端错误，表示由于缺少确定的Content-Length 首部字段，服务器拒绝客户端的请求。

注意，按照规范，当使用分块模式传输数据的时候， Content-Length 首部是不存在的，但是需要在每一个分块的开始添加该分块的长度，用十六进制数字表示。参见 Transfer-Encoding 获取更多细节信息。

4.12.1. 规范

RFC 7231, section 6.5.10: 411 Length Required

4.13. 412 Precondition Failed

服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。

在 HTTP 协议中，响应状态码 412 Precondition Failed（先决条件失败）表示客户端错误，意味着对于目标资源的访问请求被拒绝。这通常发生于采用除 GET 和 HEAD 之外的方法进行条件请求时，由首部字段 If-Unmodified-Since 或 If-None-Match 规定的先决条件不成立的情况下。这时候，请求的操作——通常是上传或修改文件——无法执行，从而返回该错误状态码。

4.13.1. 规范

RFC 7232, section 4.2: 412 Precondition Failed

4.13.2. 浏览器兼容性

4.14. 413 Payload Too Large

服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。

响应码 414 URI Too Long 表示客户端所请求的 URI 超过了服务器允许的范围。

以下是造成这种罕见情况的几种可能原因：

• 当客户端误将 POST 请求当作 GET 请求时，会带有一个较长的查询字符串(query)；
• 当客户端堕入重定向循环黑洞时，例如，指向自身后缀的重定向URI前缀(a redirected URI prefix that points to a suffix of itself)；
• 当客户端对服务器进行攻击，试图寻找潜在的漏洞时。

4.14.1. 规范

RFC 7231, section 6.5.12: 414 URI Too Long

4.15. 414 URI Too Long

请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。

响应码 414 URI Too Long 表示客户端所请求的 URI 超过了服务器允许的范围。

以下是造成这种罕见情况的几种可能原因：

• 当客户端误将 POST 请求当作 GET 请求时，会带有一个较长的查询字符串(query)；
• 当客户端堕入重定向循环黑洞时，例如，指向自身后缀的重定向URI前缀(a redirected URI prefix that points to a suffix of itself)；
• 当客户端对服务器进行攻击，试图寻找潜在的漏洞时。

4.15.1. 规范

RFC 7231, section 6.5.12: 414 URI Too Long

4.16. 415 Unsupported Media Type

对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。

415 Unsupported Media Type 是一种HTTP协议的错误状态代码，表示服务器由于不支持其有效载荷的格式，从而拒绝接受客户端的请求。

格式问题的出现有可能源于客户端在 Content-Type 或 Content-Encoding 首部中指定的格式，也可能源于直接对负载数据进行检测的结果。

4.16.1. 规范

RFC 7231, section 6.5.13: 415 Unsupported Media Type

4.17. 416 Range Not Satisfiable

如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。

HTTP 416 Range Not Satisfiable 错误状态码意味着服务器无法处理所请求的数据区间。最常见的情况是所请求的数据区间不在文件范围之内，也就是说，Range 首部的值，虽然从语法上来说是没问题的，但是从语义上来说却没有意义。

416 响应报文包含一个Content-Range 首部，提示无法满足的数据区间（用星号 * 表示），后面紧跟着一个“/”，再后面是当前资源的长度。例如：Content-Range: */12777

遇到这一错误状态码时，浏览器一般有两种策略：要么终止操作（例如，一项中断的下载操作被认为是不可恢复的），要么再次请求整个文件。

4.17.1. 规范

RFC 7233, section 4.4: 416 Request Not Satisfiable

4.17.2. 浏览器兼容性

4.18. 417 Expectation Failed

此响应代码意味着服务器无法满足Expect请求标头字段指示的期望值。

HTTP协议中的 417 Expectation Failed 状态码表示客户端错误，意味着服务器无法满足Expect请求消息头中的期望条件。

参考 Expect 消息头获得更多的相关细节信息。

4.18.1. 规范

RFC 7231, section 6.5.14: 417 Expectation Failed

4.19. 418 I’m a teapot

服务器拒绝尝试用 “茶壶冲泡咖啡”。

HTTP 418 I’m a teapot 客户端错误响应代码表示服务器拒绝冲泡咖啡，因为它是个茶壶。

该错误是超文本咖啡壶控制协议的参考，和 1998 年愚人节的玩笑。

4.19.1. 规范

RFC 2324, section 2.3.2: 418 I’m a teapot

4.19.2. 浏览器兼容性

4.20. 421 Misdirected Request

该请求针对的是无法产生响应的服务器。 这可以由服务器发送，该服务器未配置为针对包含在请求 URI 中的方案和权限的组合产生响应。

4.21. 422 Unprocessable Entity (WebDAV (en-US))

请求格式良好，但由于语义错误而无法遵循。

HTTP 422 状态码表示服务器理解请求实体的内容类型，并且请求实体的语法是正确的，但是服务器无法处理所包含的指令。

重要提示：客户端不应在不修改的情况下重复发送此请求。

4.21.1. 规范

RFC 4918, section 11.2: 422 Unprocessable Entity

4.22. 423 Locked (WebDAV (en-US))

正在访问的资源被锁定。

4.23. 424 Failed Dependency (WebDAV (en-US))

由于先前的请求失败，所以此次请求失败。

4.24. 425 Too Early

服务器不愿意冒着风险去处理可能重播的请求。

状态码 425 Too Early 代表服务器不愿意冒风险来处理该请求，原因是处理该请求可能会被“重放”，从而造成潜在的重放攻击。

4.24.1. 规范

RFC 8470, section 5.2: 425: Early Data

4.24.2. 浏览器兼容性

4.25. 426 Upgrade Required

服务器拒绝使用当前协议执行请求，但可能在客户机升级到其他协议后愿意这样做。 服务器在 426 响应中发送Upgrade (en-US) 头以指示所需的协议。

426 Upgrade Required 是一种HTTP协议的错误状态代码，表示服务器拒绝处理客户端使用当前协议发送的请求，但是可以接受其使用升级后的协议发送的请求。

服务器会在响应中使用 Upgrade (en-US) 首部来指定要求的协议。

4.25.1. 示例

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

4.25.2. 规范

RFC 7231, section 6.5.15: 426 Upgrade Required

4.26. 428 Precondition Required

原始服务器要求该请求是有条件的。 旨在防止“丢失更新”问题，即客户端获取资源状态，修改该状态并将其返回服务器，同时第三方修改服务器上的状态，从而导致冲突。

在HTTP协议中，响应状态码 428 Precondition Required 表示服务器端要求发送条件请求。

一般的，这种情况意味着必要的条件首部——如 If-Match ——的缺失。.

当一个条件首部的值不能匹配服务器端的状态的时候，应答的状态码应该是 412 Precondition Failed，前置条件验证失败。

4.26.1. 规范

RFC 6585, section 3: 428 Precondition Required

4.27. 429 Too Many Requests

用户在给定的时间内发送了太多请求（“限制请求速率”）。

在HTTP协议中，响应状态码 429 Too Many Requests 表示在一定的时间内用户发送了太多的请求，即超出了“频次限制”。

在响应中，可以提供一个 Retry-After 首部来提示用户需要等待多长时间之后再发送新的请求。

4.27.1. 示例

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

4.27.2. 规范

RFC 6585, section 4: 429 Too Many Requests

4.28. 431 Request Header Fields Too Large

服务器不愿意处理请求，因为它的 请求头字段太大（ Request Header Fields Too Large）。 请求可以在减小请求头字段的大小后重新提交。

响应码 431 Request Header Fields Too Large 表示由于请求中的首部字段的值过大，服务器拒绝接受客户端的请求。客户端可以在缩减首部字段的体积后再次发送请求。

该响应码可以用于首部总体体积过大的情况，也可以用于单个首部体积过大的情况。

这种错误不应该出现于经过良好测试的投入使用的系统当中，而是更多出现于测试新系统的时候。

4.28.1. 规范

RFC 6585, section 5: 431 Request Header Fields Too Large

4.29. 451 Unavailable For Legal Reasons

用户请求非法资源，例如：由政府审查的网页。

451 Unavailable For Legal Reasons （因法律原因不可用）是一种HTTP协议的错误状态代码，表示服务器由于法律原因，无法提供客户端请求的资源，例如可能会导致法律诉讼的页面。

4.29.1. 示例

这个响应示例来自 IETF RFC 规范（见下文），其中提到了英国戏剧电影Monty Python’s Life of Brian （《蒙提·派森之布莱恩的一生》）。

注意 Link 首部中可能会包含一个 rel=“blocked-by” 字段，用于标明为该资源无法提供负责的主体，例如颁布法令将资源删除的个人或组织的名称。

HTTP/1.1 451 Unavailable For Legal Reasons
Link: https://spqr.example.org/legislatione; rel=“blocked-by”
Content-Type: text/html

Unavailable For Legal Reasons

This request may not be serviced in the Roman Province of Judea due to the Lex Julia Majestatis, which disallows access to resources hosted on servers deemed to be operated by the People's Front of Judea.

4.29.2. 规范

RFC 7725: 451 Unavailable For Legal Reasons

4.29.3. 浏览器兼容性

5. 服务端响应

这部分的响应状态代码如下：

5.1. 500 Internal Server Error

在 HTTP 协议中，500 Internal Server Error 是表示服务器端错误的响应状态码，意味着所请求的服务器遇到意外的情况并阻止其执行请求。

这个错误代码是一个通用的“万能”响应代码。有时候，对于类似于 500 这样的错误，服务器管理员会更加详细地记录相关的请求信息来防止以后同样错误的出现。

5.1.1. 规范

RFC 7231, section 6.6.1: 500 Internal Server Error

5.1.2. 浏览器兼容性

5.2. 501 Not Implemented

此请求方法不被服务器支持且无法被处理。只有GET和HEAD是要求服务器支持的，它们必定不会返回此错误代码。

HTTP 501 Not Implemented 服务器错误响应码表示请求的方法不被服务器支持，因此无法被处理。服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET 和 HEAD。

请注意，你无法修复 501 错误，需要被访问的 web 服务器去修复该问题。

501 响应默认是可缓存的。

5.2.1. 规范

RFC 7231, section 6.6.2: 501 Not Implemented

5.2.2. 浏览器兼容性

5.3. 502 Bad Gateway

此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。

502 Bad Gateway 是一种HTTP协议的服务器端错误状态代码，它表示作为网关或代理角色的服务器，从上游服务器（如tomcat、php-fpm）中接收到的响应是无效的。

Gateway （网关）在计算机网络体系中可以指代不同的设备，502 错误通常不是客户端能够修复的，而是需要由途径的Web服务器或者代理服务器对其进行修复。

5.3.1. 规范

RFC 7231, section 6.6.3: 502 Bad Gateway

5.3.2. 浏览器兼容性

5.4. 503 Service Unavailable

服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。 请注意，与此响应一起，应发送解释问题的用户友好页面。 这个响应应该用于临时条件和 Retry-After：如果可能的话，HTTP头应该包含恢复服务之前的估计时间。 网站管理员还必须注意与此响应一起发送的与缓存相关的标头，因为这些临时条件响应通常不应被缓存。

503 Service Unavailable 是一种HTTP协议的服务器端错误状态代码，它表示服务器尚未处于可以接受请求的状态。

通常造成这种情况的原因是由于服务器停机维护或者已超载。注意在发送该响应的时候，应该同时发送一个对用户友好的页面来解释问题发生的原因。该种响应应该用于临时状况下，与之同时，在可行的情况下，应该在 Retry-After 首部字段中包含服务恢复的预期时间。

缓存相关的首部在与该响应一同发送时应该小心使用，因为 503 状态码通常应用于临时状况下，而此类响应一般不应该进行缓存。

5.4.1. 规范

RFC 7231, section 6.6.4: 503 Service Unavailable

5.4.2. 浏览器兼容性

5.5. 504 Gateway Timeout

当服务器作为网关，不能及时得到响应时返回此错误代码。

504 Gateway Timeout 是一种HTTP协议的服务器端错误状态代码，表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应。

Gateway （网关）在计算机网络体系中可以指代不同的设备，504 错误通常不是在客户端可以修复的，而是需要由途径的Web服务器或者代理服务器对其进行修复。

5.5.1. 规范

RFC 7231, section 6.6.4: 504 Gateway Timeout

5.5.2. 浏览器兼容性

5.6. 505 HTTP Version Not Supported

服务器不支持请求中所使用的HTTP协议版本。

505 HTTP Version Not Supported 是一种HTTP协议的服务器端错误状态代码，表示服务器不支持请求所使用的 HTTP 版本。

5.6.1. 规范

RFC 7231, section 6.6.6: 505 HTTP Version Not Supported

5.7. 506 Variant Also Negotiates

服务器有一个内部配置错误：对请求的透明内容协商导致循环引用。

HTTP协议的 506 Variant Also Negotiates 响应状态码 可以在TCN（透明内容协商，见RF2295）上下文给出。TCN协议允许客户端取回给定资源的最佳变量/变元，这里服务器支持多个变量/变元。

506码表示内部服务器配置错误，其中所选变量/变元自身被配置为参与内容协商，因此并不是合适的协商端点。

5.7.1. 规范

RFC 2295, section 8.1: 506 Variant Also Negotiates

5.8. 507 Insufficient Storage

服务器有内部配置错误：所选的变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当端点。

HTTP协议的 507 Insufficient Storage 响应状态码 可以在WebDAV协议（基于web的分布式创作和版本控制，参见RFC 4918）中给出。

507码表示服务器不能存储相关内容。准确地说，一个方法可能没有被执行，因为服务器不能存储其表达形式，这里的表达形式指：方法所附带的数据，而且其请求必需已经发送成功。

5.8.1. 规范

RFC 4918, section 11.5: 507 Insufficient Storage

5.9. 508 Loop Detected (WebDAV (en-US))

服务器在处理请求时检测到无限循环。

HTTP协议的 508 Loop Detected 状态码可以在WebDAV协议（基于Web的分布式创作和版本控制）中给出。

508码表示服务器中断一个操作，因为它在处理具有“Depth: infinity”的请求时遇到了一个无限循环。508码表示整个操作失败。

5.9.1. 规范

RFC 5842, section 7.2: 508 Loop Detected

5.10. 510 Not Extended

客户端需要对请求进一步扩展，服务器才能实现它。服务器会回复客户端发出扩展请求所需的所有信息。

HTTP协议的 510 Not Extended 响应状态码在HTTP扩展框架协议（参见RFC 2774）中发送。

在HTTP扩展框架协议中 ，一个客户端可以发送一个包含扩展声明的请求，该声明描述了要使用的扩展。如果服务器接收到这样的请求，但是请求不支持任何所描述的扩展，那么服务器将使用510状态码进行响应。

5.10.1. 规范

RFC 2774, section 7: 510 Not Extended

5.11. 511 Network Authentication Required

511 状态码指示客户端需要进行身份验证才能获得网络访问权限。

511 Network Authentication Required 是一种HTTP协议的错误状态代码，表示客户端需要通过验证才能使用该网络。

该状态码不是由源头服务器生成的，而是由控制网络访问的拦截代理服务器生成的。

网络运营商们有时候会在准许使用网络之前要求用户进行身份验证、接受某些条款，或者进行其他形式的与用户之间的互动（例如在网络咖啡厅或者机场）。他们通常用用户设备的 MAC 地址来进行识别。

5.11.1. 规范

RFC 6585, section 6: 511 Network Authentication Required

6. 浏览器兼容性

7. References

[1]: HTTP 响应代码