HTTP状态码详解-在线HTTP状态码对比图

HTTP 状态码

HTTP状态码详解： HTTP状态码是三位数的代码，用来表示Web服务器的HTTP响应状态。提示：Ctrl + F

HTTP 状态码	状态码的含义
100	客户端仍应发送请求。此临时响应用于通知客户端请求的一部分已被服务器接收并且尚未被拒绝。客户端应该继续发送请求的其余部分，或者在请求完成时忽略响应。完成请求后，服务器应向客户端发送最终响应。
101	服务器理解客户端的请求，并通过Upgrade消息头通知客户端使用不同的协议来完成请求。发送此响应的最后一个空行后，服务器切换到升级消息标头中定义的协议。只有在切换到新协议更有利时，才应执行类似的程序。例如，切换到较新的 HTTP 版本比旧版本具有优势。或者，切换到实时和同步协议来传输使用此类功能的资源。
102	由 WebDAV (RFC 2518) 扩展的状态代码指示处理应该继续。
200	请求成功。请求的响应标头或数据主体与此响应一起返回。
201	请求已完成，已根据请求创建新资源，其 URI 已与 Location 标头一起返回。如果无法及时建立所需的资源，则必须返回"202 已接受"。
202	服务器已接受请求但尚未处理。一个请求最终可能会或可能不会被满足，就像它可能被拒绝一样。对于异步操作，除了发送这个状态码之外没有方便的方法。返回 202 状态代码的响应的目的是允许服务器接受来自其他进程的请求（例如每天只运行一次的基于批处理的操作）。批量操作完成。接受处理请求并返回 202 状态代码的响应必须在返回的实体中包含指示处理当前状态的信息以及指向处理状态监视器或状态预测的指针。操作完成。
203	服务器成功处理了请求，但返回的实体头元信息是来自本地或第三方的副本，而不是在原始服务器上有效的确定性集合。当前信息可能是原始版本的子集或超集。例如，包括资源的元数据可能允许源服务器识别元数据。无需使用此状态代码。仅当响应中未使用此状态代码时才返回 200。情况还可以。
204	服务器成功处理了请求，但它不需要返回实体内容，它想返回更新后的元信息。响应可能会以实体标头的形式返回新的或更新的元信息。如果存在这些标头，则它们必须对应于请求的变量。如果客户端是浏览器，即使新的或更新的元信息需要应用到用户的浏览器活动文档视图中，用户的浏览器在不改变文档视图的情况下呈现请求的页面。禁止 204 响应包含消息正文，因此它始终以消息标头后的第一个空行结束。
205	服务器成功处理了请求并且没有返回任何内容。但是，与 204 响应不同，返回此状态代码的响应需要请求者重置文档视图。此响应主要用于在接受用户输入后立即重置表单，以便用户可以轻松地开始另一个输入。与 204 响应一样，响应也被禁止包含消息正文，以消息标头后的第一个空行结束。
206	服务器成功处理了一些 GET 请求。 FlashGet、迅雷等HTTP下载工具就是利用这种响应来实现断点重启或者将大文件拆分成多个下载段同时下载。该请求必须包含一个 Range 标头，指示客户端想要的内容范围，并且可以包含 If-Range 作为请求条件。响应必须包含以下标头字段： Content-Range 用于表示本次响应返回的内容范围。对于具有多部分/字节范围 Content-Type 的多段下载，每个多部分段必须包含一个 Content-Range 域，用于指示该段落的范围。如果响应中包含 Content-Length，则其值应与返回内容范围内的实际字节数相匹配。日期 ETag 和/或内容位置（如果相同的请求应返回 200 响应）。 Expires、Cache-Control 和/或 Vary 值可能与同一变量的其他先前响应中的相应值不同。如果此响应请求使用 If-Range 强缓存验证，请不要在此响应中包含任何其他实体标头。如果此响应请求使用 If-Range 弱缓存验证，则此响应不得包含任何其他实体标头。这避免了缓存的实体内容和更新的实体头信息之间的不一致。否则，此响应必须包含应在 200 响应中返回的所有实体标头字段。如果 ETag 或 Last-Modified 标头不完全匹配，客户端缓存应避免将 206 响应返回的内容与先前缓存的内容组合。禁止不支持 Range 和 Content-Range 标头的缓存缓存 206 响应返回的内容。
207	由 WebDAV (RFC 2518) 扩展的状态代码表示后续的消息主体将是一个 XML 消息，并且可能包含一系列独立的响应代码，具体取决于先前的子请求的数量。
300	请求的资源有一组可选的反馈信息，每一个都有一个唯一的地址和浏览器驱动的协商信息。用户或浏览器可以选择首选地址进行重定向。除非这是一个 HEAD 请求，否则响应应该包含一个包含资源特征和地址列表的实体，用户或浏览器可以从中选择最合适的重定向地址。该实体的格式由 Content-Type 中定义的格式决定。浏览器可能会根据响应的格式和浏览器本身的功能自动做出最合适的选择。当然，RFC 2616 规范没有指定这种自动选择应该如何进行。如果服务器本身已经有一个首选的反馈选项，那么 Location URI 应该在 Location 中指定。浏览器可以使用这个 Location 值作为自动重定向的地址。除非另有说明，否则此响应也是可缓存的。
301	请求的资源已移动到一个全新的位置。以后对该资源的引用应使用此响应中返回的多个 URI 之一。如果可能，具有链接编辑功能的客户端应自动将请求的地址更改为服务器返回的地址。除非另有说明，否则此响应也是可缓存的。应在响应的 Location 字段中返回新的永久 URI。除非这是一个 HEAD 请求，否则响应实体应该包含指向新 URI 的超链接和简短描述。如果这不是 GET 或 HEAD 请求，请求的条款可能会相应更改，因此浏览器不会自动重定向，除非用户确认。注意：在某些使用 HTTP/1.0 协议的浏览器中，向 POST 请求发送 301 响应将导致下一个重定向请求的 GET。
302	请求的资源现在临时响应来自另一个 URI 的请求。此重定向是暂时的，客户端应继续向原始地址发送请求。此响应仅在由 Cache-Control 或 Expires 指定时才可缓存。应在响应的 Location 字段中返回新的临时 URI。除非这是一个 HEAD 请求，否则响应实体应该包含指向新 URI 的超链接和简短描述。如果这不是 GET 或 HEAD 请求，请求的条款可能会相应更改，因此浏览器将不允许自动重定向，除非用户确认。注意：虽然 RFC 1945 和 RFC 2068 规范不允许客户端在重定向期间更改请求的方法，但许多现有浏览器将 302 响应视为 303 响应，并且无论位置如何，都使用 GET 访问 Location 指定的 URI。 URI。最初请求的方法。添加状态代码 303 和 307 以阐明服务器期望客户端执行的操作。
303	对应于当前请求的响应可以在另一个 URI 中找到，客户端应该使用 GET 来访问该资源。此方法的存在主要是为了允许将脚本激活的 POST 请求的输出重定向到新资源。这个新的 URI 不是对原始资源的替代引用。同时禁止缓存303响应。当然你也可以缓存第二个请求（重定向）。应在响应的 Location 字段中返回新的 URI。除非这是一个 HEAD 请求，否则响应实体应该包含指向新 URI 的超链接和简短描述。注意：许多 HTTP/1.1 之前的浏览器无法正确识别 303 状态。如果您关心与这些浏览器的交互，302 状态代码就足够了。这是因为大多数浏览器处理 302 响应的方式与客户端在处理上述规范中的 303 响应时应该做的完全一样。
304	如果客户端发送了一个有条件的 GET 请求，请求被授予，并且文档内容没有改变（自上次访问以来或根据请求的条件），服务器应该返回此状态代码。禁止 304 响应包含消息正文，因此它始终以消息标头后的第一个空行结束。响应应包含以下标头：日期，除非此服务器没有时钟。如果无时钟服务器也遵守这些规则，代理服务器和客户端可以在收到的响应头中添加一个日期字段（根据 RFC）。 2068)，缓存机制工作正常。 ETag 和/或 Content-Location（如果相同的请求应返回 200 响应）。 Expires、Cache-Control 和/或 Vary 值可能与同一变量的其他先前响应中的相应值不同。如果此响应请求使用强缓存身份验证，请不要在此响应中包含任何其他实体标头。否则（例如，如果条件 GET 请求使用弱缓存身份验证），则禁止在此响应中包含其他实体标头。这避免了缓存的实体内容和更新的实体头信息之间的不一致。如果 304 响应表明该实体当前未被缓存，则缓存系统应忽略该响应并重复发送不包含限制的请求。当收到要求更新缓存条目的 304 响应时，缓存系统必须更新整个条目以反映响应中所有字段的更新值。
305	请求的资源必须可以通过指定的代理访问。 Location 字段提供指定代理的 URI 信息。接收者必须重复发送另一个请求才能通过此代理访问相应的资源。只有源服务器才能建立 305 响应。注意：RFC 2068 没有针对重定向单个请求的显式 305 响应，它只能由源服务器建立。忽略这些限制可能会导致严重的安全后果。
306	最新版本的规范不再使用 306 状态码。
307	请求的资源现在临时响应来自另一个 URI 的请求。此重定向是暂时的，客户端应继续向原始地址发送请求。此响应仅在由 Cache-Control 或 Expires 指定时才可缓存。应在响应的 Location 字段中返回新的临时 URI。除非这是一个 HEAD 请求，否则响应实体应该包含指向新 URI 的超链接和简短描述。有些浏览器无法理解 307 响应，因此您需要在上面添加必要的信息，以便用户能够理解并发出访问新 URI 的请求。如果这不是 GET 或 HEAD 请求，请求的条款可能会相应更改，因此浏览器将不允许自动重定向，除非用户确认。
400	1、语义不正确，服务器无法理解当前请求。除非更改，否则客户端不得重复发送此请求。 2、请求参数错误。
401	当前请求需要用户身份验证。响应必须包含适合所请求资源的 WWW-Authenticate 标头，以提示用户输入信息。客户端可以重复发送带有适当授权标头的请求。如果当前请求已经包含身份验证证书，则 401 响应意味着服务器已确认这些证书已被拒绝。如果 401 响应包含与先前响应相同的身份验证质询，并且浏览器至少尝试过一次身份验证，则浏览器应向用户显示响应中包含的实体信息。这是因为这个实体信息可能包含相关的诊断信息。参见 RFC 2617.
402	此状态代码保留供将来需要。
403	服务器理解请求但拒绝执行它。与 401 响应不同，身份验证不会以任何方式帮助您，所以不要重新发送此请求。如果这不是 HEAD 请求，并且您希望服务器能够解释为什么无法满足请求，实体应该解释拒绝的原因。当然，如果服务器不想让客户端获取信息，也可以返回404响应。
404	请求失败，在服务器上找不到请求的资源。没有信息告诉用户这种情况是暂时的还是永久的。如果服务器知道这种情况，它应该使用 410 状态代码告诉旧资源由于其内部配置机制出现问题而永久不可用并且它没有地址可以跳转到。当服务器不想透露请求被拒绝的原因或没有其他适当的响应时，广泛使用 404 状态代码。
405	无法使用请求行中指定的请求方法请求相应的资源。响应应返回一个 Allow 标头以指示当前资源可以接受的请求方法列表。考虑到 PUT，DELETE 方法将资源写入服务器，因此大多数 Web 服务器在其默认配置中不支持或不允许上述请求方法，并为此类请求返回 405 错误。
406	请求资源的内容特征不满足请求头中的条件，无法生成响应实体。除非这是一个 HEAD 请求，否则响应应该返回一个包含实体属性和地址列表的实体，用户或浏览器可以从中选择最合适的一个。实体的格式由 Content-Type 标头中定义的媒体类型决定。浏览器可以根据格式和独特的功能做出最佳选择。然而，本规范没有定义进行这种自动选择的标准。
407	类似于 401 响应，但客户端必须通过代理服务器进行身份验证。代理服务器必须为身份查询返回 Proxy-Authenticate。客户端可以返回 Proxy-Authorization 标头进行验证。参见 RFC 2617.
408	请求超时。客户端在服务器准备等待的时间内没有完成发送请求。客户端始终可以不加修改地重新发送此请求。
409	请求无法完成，因为它与所请求资源的当前状态冲突。仅当用户可以解决冲突并重新提交新请求时才允许使用此代码。响应应包含足够的信息，以便用户发现冲突的原因。冲突通常发生在 PUT 请求的处理过程中。例如，在版本检查环境中，如果PUT发送的特定资源修改请求所附带的版本信息与之前的（第三方）请求冲突，此时服务器应该返回409错误。通知用户请求无法完成。此时，响应实体可能包含两个冲突版本之间差异的比较，以便用户可以在合并后重新提交新版本。
410	所请求的资源在服务器上不再可用，并且没有已知的转发地址。这种情况应该被认为是永久性的。如果可能，具有链接编辑功能的客户端应在获得用户许可后删除对该地址的所有引用。如果服务器不知道或不确定这种情况是否是永久性的，它应该使用 404 状态代码。除非另有说明，否则此响应是可缓存的。 410 响应的主要目的是让站长维护网站，通知用户该资源不再可用，以及让服务器所有者删除对该资源的所有远程连接。仅此而已。像这样的事件在限时增值业务中屡见不鲜。类似地，410 响应也用于通知当前服务器站点的客户端，原属于个人的资源不再可用。当然，是不是所有永久不可用的资源都应该标记为"410"？该标签应保留多长时间完全取决于服务器所有者。
411	服务器拒绝接受未定义 Content-Length 标头的请求。在添加一个有效的 Content-Length 标头指示请求消息体的长度后，客户端可以再次发送请求。
412	在检查请求标头字段中指定的先决条件时，服务器无法满足其中一项或多项。此状态码允许客户端在检索资源时对请求的元信息（请求头字段数据）设置前置条件，以防止请求方法应用于所需内容以外的资源。。
413	服务器拒绝处理当前请求，因为请求发送的实体数据的大小超出了服务器正在尝试处理或可以处理的大小。在这种情况下，服务器可以关闭连接以防止客户端继续发送此请求。如果这种情况是暂时的，服务器应该返回一个 Retry-After 响应头来告诉客户端稍后可以重试多少次。
414	服务器拒绝处理请求，因为请求 URI 长于服务器可以解释的长度。这种情况比较少见，通常情况是：应该使用 POST 方法的表单提交现在是 GET 方法和查询字符串（Query 字符串）太长。重定向 URI 中的"黑洞"。例如，每次重定向都使用旧 URI 作为新 URI 的一部分，导致多次重定向后 URI 更长。客户端试图攻击在某些服务器上存在安全漏洞的服务器。这种类型的服务器使用固定长度的缓冲区来读取和操作请求 URI。如果 post-GET 参数超过某个值，可能会发生缓冲区溢出并可能执行任意代码 [1]。没有此类漏洞的服务器应返回 414 状态代码。
415	对于当前请求的方法和请求的资源，请求被拒绝，因为请求中发送的实体不是服务器支持的格式。
416	如果请求中包含Range请求头，Range中指定的数据范围与当前资源的可用范围不匹配，且请求中未定义If-Range请求头，服务器返回416状态应该返回代码。如果Range使用字节范围，这种情况意味着请求指定的所有数据范围的第一个字节位置超过了当前资源的长度。服务器还应返回 416 状态代码，并包含一个 Content-Range 实体标头，指示当前资源的长度。此响应还不允许使用 multipart / byteranges 作为内容类型。
417	要么Request header的Expect中指定的期望没有被服务器满足，要么有明确的证据表明服务器是代理服务器，当前路由中的下一个节点不满足Expect的内容。我有。
421	从当前客户端的 IP 地址到服务器的连接数已超过服务器允许的最大范围。这里的IP地址通常是指服务器看到的客户端地址（如用户网关或代理服务器的地址）。在这种情况下，多个最终用户可能会参与计算连接数。
422	从当前客户端的 IP 地址到服务器的连接数已超过服务器允许的最大范围。这里的IP地址通常是指服务器看到的客户端地址（如用户网关或代理服务器的地址）。在这种情况下，多个最终用户可能会参与计算连接数。
422	请求格式正确，但包含语义错误，无法响应。 (RFC 4918 WebDAV) 423 Locked 当前资源被锁定。 (RFC 4918 WebDAV)
424	当前请求因先前请求（如 PROPPATCH）中的错误而失败。 (RFC 4918 WebDAV)
425	在 WebDav 高级集合草案中定义，但未出现在 WebDAV 序列集协议 (RFC 3658) 中。
426	客户端应切换到 TLS/1.0。 (RFC2817)
449	由 Microsoft 增强，应在采取适当措施后重试代表请求。
500	服务器遇到意外情况，无法完成您的请求。一般在服务器程序代码不正确时会出现此问题。
501	服务器不支持当前请求所需的功能。如果服务器无法识别请求的方法并且无法支持该资源请求。
502	充当网关或代理的服务器在尝试完成请求时收到来自上游服务器的无效响应。
503	由于临时服务器维护或过载，服务器当前无法处理请求。这种状态是暂时的，过一段时间就会恢复正常。如果可以估计延迟，则响应可以包含指示延迟的 Retry-After 标头。如果未提供此 Retry-After 信息，客户端应将其视为 500 响应。注意：503 状态代码的存在并不意味着它应该在服务器过载时使用。有些服务器只是想拒绝客户端连接。
504	当充当网关或代理的服务器试图完成请求时，它无法从上游服务器（由 URI 标识的服务器，如 HTTP、FTP、LDAP 等）或辅助服务器（DNS 等）接收响应。 ). 快速地。注意：某些代理服务器在 DNS 查询超时时返回 400 或 500 错误。
505	服务器不支持或拒绝支持请求中使用的 HTTP 版本。这意味着服务器不能或不想使用与客户端相同的版本。响应必须包含一个实体来解释为什么不支持该版本以及服务器支持哪些协议。
506	由透明内容协商协议 (RFC 2295) 扩展以表示内部服务器配置错误。
507	服务器无法存储完成请求所需的内容。这种情况被认为是暂时的。 WebDAV（RFC 4918）
509	服务器已达到其带宽限制。这不是官方状态代码，但仍被广泛使用。
510	获取资源所需的策略并不充分。 (RFC2774)

其他工具