关于http:常见的HTTP状态码

本内容摘抄自《RESTful WebServices》中文译本附录 B ’42 种常见的 HTTP 响应代码 ’。
原文作者：Leonard Ricbardson & Sam Ruby
翻译：徐涵、李红军、胡伟

1、三至七种最根本的响应代码

• 200(“OK”)
  一切正常。实体主体中的文档（若存在的话）是某资源的示意。
• 400(“Bad Request”)
  客户端方面的问题。实体主题中的文档（若存在的话）是一个谬误音讯。心愿客户端可能了解此谬误音讯，并改过问题。
• 500(“Internal Server Error”)
  服务期方面的问题。实体主体中的文档（如果存在的话）是一个谬误音讯。该谬误音讯通常杯水车薪，因为客户端无奈修复服务器方面的问题。
• 301(“Moved Permanently”)
  当客户端触发的动作引起了资源 URI 的变动时发送此响应代码。另外，当客户端向一个资源的旧 URI 发送申请时，也发送此响应代码。
• 404(“Not Found”) 和 410(“Gone”)
  当客户端所申请的 URI 不对应于任何资源时，发送此响应代码。404 用于服务器端不晓得客户端要申请哪个资源的状况；410 用于服务器端晓得客户端所申请的资源已经存在，但当初曾经不存在了的状况。
• 409(“Conflict”)
  当客户端试图执行一个”会导致一个或多个资源处于不统一状态“的操作时，发送此响应代码。

SOAP Web 服务只应用响应代码 200(“OK”)和 500(“Internal Server Error”)。无论是你发给 SOAP 服务器的数据有问题，还是服务器在解决数据的过程中呈现问题，或者 SOAP 服务器呈现外部问题，SOAP 服务器均发送 500(“Internal Server Error”)。客户端只有查看 SOAP 文档主体（body）（其中蕴含谬误的形容）能力获知谬误起因。客户端无奈仅靠读取响应的前三个字节得悉申请胜利与否。

2、状态码系列。

1XX：告诉

1XX 系列响应代码仅在与 HTTP 服务器沟通时应用。

• 100(“Continue”)
  重要水平：中等，但（写操作时）很少用。

这是对 HTTP LBYL（look-before-you-leap）申请的一个可能的响应。该响应代码表明：客户端应从新发送初始申请，并在申请中附上第一次申请时未提供的（可能很大或者蕴含敏感信息的）示意。客户端这次发送的申请不会被回绝。对 LBYL 申请的另一个可能的响应是 417(“Expectation Failed”)。

申请报头：要做一个 LBYL 申请，客户端必须把 Expect 申请报头设为字符串 ”100-continue”。除此以外，客户端还须要设置其余一些报头，服务器将依据这些报头决定是响应 100 还是 417。

• 101(“Switching Protocols”)
  重要水平：非常低。

当客户端通过在申请里应用 Upgrade 报头，以告诉服务器它想改用除 HTTP 协定之外的其余协定时，客户端将取得此响应代码。101 响应代码示意“行，我当初改用另一个协定了”。通常 HTTP 客户端会在收到服务器发来的 101 响应后敞开与服务器的 TCP 连贯。101 响应代码意味着，该客户端不再是一个 HTTP 客户端，而将成为另一种客户端。
只管能够通过 Upgrade 报头从 HTTP 切换到 HTTPS，或者从 HTTP1.1 切换到某个将来的版本，但理论应用 Upgrade 报头的状况比拟少。Upgrade 报头也可用于 HTTP 切换到一个齐全不同的协定（如 IRC）上，但那须要在 Web 服务器切换为一个 IRC 服务器的同时，Web 客户端切换为一个 IRC 的客户端，因为服务器将立即在同一个 TCP 连贯上开始应用新的协定。

申请报头：客户端把 Upgrade 报头设置为一组心愿应用的协定。
响应报头：如果服务器批准切换协定，它就返回一个 Upgrade 报头，阐明它将切换到那个协定，并附上一个空白行。服务器不必敞开 TCP 链接，而是间接在该 TCP 连贯上开始应用新的协定。

2XX: 胜利

2XX 系列响应代码表明操作胜利了。

• 200(“OK”)
  重要水平：十分高。

一般来说，这是客户端心愿看到的响应代码。它示意服务器胜利执行了客户端所申请的动作，并且在 2XX 系列里没有其余更适宜的响应代码了。

实体主体：对于 GET 申请，服务器应返回客户端所申请资源的一个示意。对于其余申请，服务器应返回以后所选资源的一个示意，或者刚刚执行的动作的一个形容。

-201(“Created”)
重要水平：高。

当服务器按照客户端的申请创立了一个新资源时，发送此响应代码。

响应报头：Location 报头应蕴含指向新创建资源的标准 URI。
实体主体：应该给出新创建资源的形容与链接。若曾经在 Location 报头里给出了新资源的 URI，那么能够用新资源的一个示意作为实体主体。

-202(“Accepted”)
重要水平：中等。

客户端的申请无奈或将不被实时处理。申请稍后会被解决。申请看上去是非法的，但在理论解决它时有呈现问题的可能。
若一个申请触发了一个异步操作，或者一个须要事实世界参加的动作，或者一个须要很长时间能力实现且没必要让 Web 客户端始终期待的动作时，这个相应代码是一个适合的抉择。

响应报头：应该把未解决完的申请裸露为一个资源，以便客户端稍后查问其状态。Location 报头能够蕴含指向该资源的 URI。
实体主体：若无奈让客户端稍后查问申请的状态，那么至多应该提供一个对于何时能解决该申请的预计。

• 203(“Non-Authoritative Information”)
  重要水平：非常低。

这个响应代码跟 200 一样，只不过服务器想让客户端晓得，有些响应报头并非来自该服务器 – 他们可能是从客户端先前发送的一个申请里复制的，或者从第三方失去的。

响应报头：客户端应明确某些报头可能是不精确的，某些响应报头可能不是服务器本人生成的，所以服务器也不晓得其含意。

• 204(“No Content”)
  重要水平：高。

若服务器回绝对 PUT、POST 或者 DELETE 申请返回任何状态信息或示意，那么通常采纳此响应代码。服务器也能够对 GET 申请返回此响应代码，这表明“客户端申请的资源存在，但其示意是空的”。留神与 304(“Not Modified”)的区别。204 经常用在 Ajax 利用里。服务器通过这个响应代码通知客户端：客户端的输出已被承受，但客户端不应该扭转任何 UI 元素。

实体主体：不容许。

• 205(“Reset Content”)
  重要水平：低。

它与 204 相似，但与 204 不同的是，它表明客户端应重置数据源的视图或数据结构。如果你在浏览器里提交一个 HTML 表单，并失去响应代码 204，那么表单里的各个字段值不变，能够持续批改它们；但如果失去的响应代码 205，那么表单里的各个字段将被重置为它们的初始值。从数据录入方面讲：204 适宜对单条记录做一系列编辑，而 205 适于间断输出一组记录。

• 206(“Partial Content”)
  重要水平：对于反对局部 GET（partial GET）的服务而言“十分高”，其余状况下“低”。

它跟 200 相似，但它用于对局部 GET 申请（即应用 Range 申请报头的 GET 申请）的响应。局部 GET 申请罕用于大型二进制文件的断点续传。

申请报头：客户端为 Range 申请报头设置一个值。
响应报头：须要提供 Date 报头。ETag 报头与 Content-Location 报头的值应该跟失常 GET 申请雷同。

若实体主体是单个字节范畴（byte range），那么 HTTP 响应里必须蕴含一个 Content-Range 报头，以阐明本响应返回的是示意的哪个局部，若实体主体是一个多局部实体（multipart entity）（即该实体主体由多个字节范畴形成），那么每一个局部都要有本人的 Content-Range 报头。
实体主体：不是整个示意，而是一个或者多个字节范畴。

3XX 重定向

3XX 系列响应代码表明：客户端须要做些额定工作能力失去所须要的资源。它们通常用于 GET 申请。他们通常通知客户端须要向另一个 URI 发送 GET 申请，能力失去所需的示意。那个 URI 就蕴含在 Location 响应报头里。

• 300(“Multiple Choices”)
  重要水平：低。

若被申请的资源在服务器端存在多个示意，而服务器不晓得客户端想要的是哪一个示意时，发送这个响应代码。或者当客户端没有应用 Accept-* 报头来指定一个示意，或者客户端所申请的示意不存在时，也发送这个响应代码。在这种状况下，一种抉择是，服务器返回一个首选示意，并把响应代码设置为 200，不过它也能够返回一个蕴含该资源各个示意的 URI 列表，并把响应代码设为 300。

响应报头：如果服务器有首选示意，那么它能够在 Location 响应报头中给出这个首选示意的 URI。跟其余 3XX 响应代码一样，客户端能够主动追随 Location 中的 URI。
实体主体：一个蕴含该资源各个示意的 URI 的列表。能够在示意中提供一些信息，以便用户作出抉择。

• 301(“Moved Permanently”)
  重要水平：中等。

服务器晓得客户端试图拜访的是哪个资源，但它不喜爱客户端用以后 URI 来申请该资源。它心愿客户端记住另一个 URI，并在今后的申请中应用那个新的 URI。你能够通过这个响应代码来避免因为 URI 变更而导致老 URI 生效。

响应报头：服务器该当把标准 URI 放在 Location 响应报头里。
实体主体：服务器能够发送一个蕴含新 URI 的信息，不过这不是必须的。

• 302(“Found”)
  重要水平：应该理解，特地市编写客户端时。但我不举荐应用它。

这个响应代码市造成大多数重定向方面的凌乱的最根本原因。它应该是像 307 那样被解决。实际上，在 HTTP 1.0 中，响应代码 302 的名称是”Moved Temporarily”，可怜的是，在理论生存中，绝大多数客户端拿它像 303 一样解决。它的不同之处在于当服务器为客户端的 PUT，POST 或者 DELETE 申请返回 302 响应代码时，客户端要怎么做。
为了打消这一混同，在 HTTP 1.1 中，该响应代码被重命名为 ”Found”，并新加了一个响应代码 307。这个响应代码目前仍在宽泛应用，但它的含意市混同的，所以我倡议你的服务发送 307 或者 303，而不要发送 302. 除非你晓得正在与一个不能了解 303 或 307 的 HTTP 1.0 客户端交互。

响应报头：把客户端应从新申请的那个 URI 放在 Location 报头里。
实体主体：一个蕴含指向新 URI 的链接的超文本文档（就像 301 一样）。

• 303(“See Other”)
  重要水平：高。

申请曾经被解决，但服务器不是间接返回一个响应文档，而是返回一个响应文档的 URI。该响应文档可能是一个动态的状态信息，也可能是一个更乏味的资源。对于后一种状况，303 是一种令服务器能够“发送一个资源的示意，而不强制客户端下载其所有数据”的形式。客户端能够向 Location 报头里的 URI 发送 GET 申请，但它不是必须这么做。
303 响应代码是一种规范化资源 URI 的好方法。一个资源能够有多个 URIs，但每个资源的标准 URI 只有一个，该资源的所有其余 URIs 都通过 303 指向该资源的标准 URI，例如：303 能够把一个对 http://www.example.com/softwa…://www.example.com/software/1.0.2.tar.gz。

响应报头：Location 报头里蕴含资源的 URI。
实体主体：一个蕴含指向新 URI 的链接的超文本文档。

• 304(“Not Modified”)
  重要水平：高。

这个响应代码跟 204(“No Content”)相似：响应实体主体都必须为空。但 204 用于没有主体数据的状况，而 304 用于有主体数据，但客户端已领有该数据，没必要反复发送的状况。这个响应代码可用于条件 HTTP 申请（conditional HTTP request). 如果客户端在发送 GET 申请时附上了一个值为 Sunday 的 If-Modified-Since 报头，而客户端所申请的示意在服务器端自星期日（Sunday）以来始终没有扭转过，那么服务器能够返回一个 304 响应。服务器也能够返回一个 200 响应，但因为客户端已领有该示意，因而反复发送该示意只会白白浪费宽带。

响应报头：须要提供 Date 报头。Etag 与 Content-Location 报头的值，应该跟返回 200 响应时的一样。若 Expires, Cache-Control 及 Vary 报头的值自上次发送以来曾经扭转，那么就要提供这些报头。
实体主体：不容许。

• 305(“Use Proxy”)
  重要水平：低。

这个响应代码用于通知客户端它须要再发一次申请，但这次要通过一个 HTTP 代理发送，而不是间接发送给服务器。这个响应代码应用的不多，因为服务器很少在意客户端是否应用某一特定代理。这个代码次要用于基于代理的镜像站点。当初，镜像站点（如 http://www.example.com.mysite…）蕴含跟原始站点（如 http://www.example.com/）一样的内容，但具备不同的 URI，原始站点能够通过 307 把客户端从新定向到镜像站点上。如果有基于代理的镜像站点，那么你能够通过把 http://proxy.mysite.com/ 设为代理，应用跟原始 URI（http://www.example.com/）一样的 URI 来拜访镜像站点。这里，原始站点 example.com 能够通过 305 把客户端路由到一个天文上靠近客户端的镜像代理。web 浏览器个别不能正确处理这个响应代码，这是导致 305 响应代码用的不多的另一个起因。

响应报头：Location 报头里蕴含代理的 URI。

• 306 未应用
  重要水平：无

306 响应代码没有在 HTTP 规范中定义过。

• 307(“Temporary Redirect”)
  重要水平：高。

申请还没有被解决，因为所申请的资源不在本地：它在另一个 URI 处。客户端应该向那个 URI 从新发送申请。就 GET 申请来说，它只是申请失去一个示意，该响应代码跟 303 没有区别。当服务器心愿把客户端从新定向到一个镜像站点时，能够用 307 来响应 GET 申请。但对于 POST，PUT 及 DELETE 申请，它们心愿服务器执行一些操作，307 和 303 有显著区别。对 POST，PUT 或者 DELETE 申请响应 303 表明：操作曾经胜利执行，但响应实体将不随本响应一起返回，若客户端想要获取响应实体主体，它须要向另一个 URI 发送 GET 申请。而 307 表明：服务器尚未执行操作，客户端须要向 Location 报头里的那个 URI 从新提交整个申请。

响应报头：把客户端应从新申请的那个 URI 放在 Location 报头里。
实体主体：一个蕴含指向新 URI 的链接的超文本文档。

4XX：客户端谬误

这些响应代码表明客户端呈现谬误。不是认证信息有问题，就是示意格局或 HTTP 库自身有问题。客户端须要自行改过。

• 400(“Bad Request”)
  重要水平：高。

这是一个通用的客户端谬误状态，当其余 4XX 响应代码不实用时，就采纳 400。此响应代码通常用于“服务器收到客户端通过 PUT 或者 POST 申请提交的示意，示意的格局正确，但服务器不懂它什么意思”的状况。

实体主体：能够蕴含一个谬误的形容文档。

• 401(“Unauthorized”)
  重要水平：高。

客户端试图对一个受爱护的资源进行操作，却又没有提供正确的认证证书。客户端提供了谬误的证书，或者基本没有提供证书。这里的证书（credential）能够是一个用户名 / 明码，也能够市一个 API key，或者一个认证令牌。客户端经常通过向一个 URI 发送申请，并查看收到 401 响应，以获知应该发送哪种证书，以及证书的格局。如果服务器不想让未受权的用户获知某个资源的存在，那么它能够谎报一个 404 而不是 401。这样做的毛病是：客户端须要当时晓得服务器承受哪种认证 – 这将导致 HTTP 摘要认证无奈工作。

响应报头：WWW-Authenticate 报头形容服务器将承受哪种认证。
实体主体：一个谬误的形容文档。如果最终用户可通过“在网站上注册”的形式失去证书，那么应提供一个指向该注册页面的链接。

• 402(“Payment Required”)
  重要水平：无。

除了它的名字外，HTTP 规范没有对该响应的其余方面作任何定义。因为目前还没有用于 HTTP 的微领取零碎，所以它被留作未来应用。尽管如此，若存在一个用于 HTTP 的微领取零碎，那么这些零碎将首先呈现在 web 服务畛域。如果想按申请向用户免费，而且你与用户之间的关系容许这么做的话，那么或者用得上这个响应代码。
注：该书印于 2008 年

• 403(“Forbidden”)
  重要水平：中等。

客户端申请的构造正确，然而服务器不想解决它。这跟证书不正确的状况不同 – 若证书不正确，应该发送响应代码 401。该响应代码罕用于一个资源只容许在特定时间段内拜访，
或者容许特定 IP 地址的用户拜访的状况。403 暗示了所申请的资源的确存在。跟 401 一样，若服务器不想走漏此信息，它能够谎报一个 404。既然客户端申请的构造正确，那为什么还要把本响应代码放在 4XX 系列（客户端谬误），而不是 5XX 系列（服务端谬误）呢？因为服务器不是依据申请的构造，而是依据申请的其余方面（比如说发出请求的工夫）作出的决定的。

实体主体：一个形容回绝起因的文档（可选）。

• 404(“Not Found”)
  重要水平：高。

这兴许是最广为人知的 HTTP 响应代码了。404 表明服务器无奈把客户端申请的 URI 转换为一个资源。相比之下，410 更有用一些。web 服务能够通过 404 响应通知客户端所申请的 URI 是空的，而后客户端就能够通过向该 URI 发送 PUT 申请来创立一个新资源了。然而 404 也有可能是用来拆穿 403 或者 401.

• 405(“Method Not Allowd”)
  重要水平：中等。

客户端试图应用一个本资源不反对的 HTTP 办法。例如：一个资源只反对 GET 办法，然而客户端应用 PUT 办法拜访。

响应报头：Allow 报头列出本资源反对哪些 HTTP 办法，例如：Allow：GET，POST

• 406(“Not Acceptable”)
  重要水平：中等。

当客户端对示意有太多要求，以至于服务器无奈提供满足要求的示意，服务器能够发送这个响应代码。例如：客户端通过 Accept 头指定媒体类型为 application/json+hic，然而服务器只反对 application/json。服务器的另一个抉择是：疏忽客户端挑剔的要求，返回首选示意，并把响应代码设为 200。

实体主体：一个可选示意的链接列表。

• 407(“Proxy Authentication Required”)
  重要水平：低。

只有 HTTP 代理会发送这个响应代码。它跟 401 相似，惟一区别在于：这里不是无权拜访 web 服务，而是无权拜访代理。跟 401 一样，可能是因为客户端没有提供证书，也可能是客户端提供的证书不正确或不充沛。

申请报头：客户端通过应用 Proxy-Authorization 报头（而不是 Authorization）把证书提供给代理。格局跟 Authrization 一样。
响应报头：代理通过 Proxy-Authenticate 报头（而不是 WWW-Authenticate）通知客户端它承受哪种认证。格局跟 WWW-Authenticate 一样。

• 408(“Reqeust Timeout”)
  重要水平：低。

如果 HTTP 客户端与服务器建设链接后，却不发送任何申请（或从不发送表明申请完结的空白行），那么服务器最终应该发送一个 408 响应代码，并敞开此连贯。

• 409(“Conflict”)
  重要水平：高。

此响应代码表明：你申请的操作会导致服务器的资源处于一种不可能或不统一的状态。例如你试图批改某个用户的用户名，而批改后的用户名与其余存在的用户名抵触了。

响应报头：若抵触是因为某个其余资源的存在而引起的，那么应该在 Location 报头里给出那个资源的 URI。
实体主体：一个形容抵触的文档，以便客户端能够解决抵触。

• 410(“Gone”)
  重要水平：中等。

这个响应代码跟 404 相似，但它提供的有用信息更多一些。这个响应代码用于服务器晓得被申请的 URI 过来曾指向一个资源，但该资源当初不存在了的状况。服务器不晓得
该资源的新 URI，服务器要是晓得该 URI 的话，它就发送响应代码 301.410 和 310 一样，都有暗示客户端不应该再申请该 URI 的意思，不同之处在于：410 只是指出该资源不存在，但没有给出该资源的新 URI。RFC2616 倡议“为短期的推广服务，以及属于集体但不持续在服务端运行的资源”采纳 410.

• 411(“Length Required”)
  重要水平：低到中等。

若 HTTP 申请蕴含示意，它应该把 Content-Length 申请报头的值设为该示意的长度（以字节为单位）。对客户端而言，有时这不太不便（例如，当示意是来自其余起源的字节流时）。
所以 HTTP 并不要求客户端在每个申请中都提供 Content-Length 报头。但 HTTP 服务器能够要求客户端必须设置该报头。服务器能够中断任何没有提供 Content-Length 报头的申请，并要求客户端从新提交蕴含 Content-Length 报头的申请。这个响应代码就是用于中断未提供 Content-Lenght 报头的申请的。如果客户端提供谬误的长度，或发送超过长度的示意，服务器能够中断请求并敞开链接，并返回响应代码 413。

• 412(“Precondition Failed”)
  重要水平：中等。

客户端在申请报头里指定一些前提条件，并要求服务器只有在满足肯定条件的状况下能力解决本申请。若服务器不满足这些条件，就返回此响应代码。If-Unmodified-Since 是一个常见的前提条件。客户端能够通过 PUT 申请来批改一个资源，但它要求，仅在自客户端最初一次获取该资源后该资源未被他人批改过能力执行批改操作。若没有这一前提条件，客户端可能会有意识地笼罩他人做的批改，或者导致 409 的产生。

申请报头：若客户但设置了 If-Match，If-None-Match 或 If-Unmodified-Since 报头，那就有可能失去这个响应代码。If-None-Match 略微特地一些。若客户端在发送 GET 或 HEAD 申请时指定了 If-None-Match，并且服务器不满足该前提条件的话，那么响应代码不是 412 而是 304，这是实现条件 HTTP GET 的根底。若客户端在发送 PUT，POST 或 DELETE 申请时指定了 If-None-Match, 并且服务器不满足该前提条件的话，那么响应代码是 412. 另外，若客户端指定了 If-Match 或 If-Unmodified-Since(无论采纳什么 HTTP 办法)，而服务器不满足该前提条件的话，响应代码也是 412。

• 413(“Request Entity Too Large”)
  重要水平：低到中等。

这个响应代码跟 411 相似，服务器能够用它来中断客户端的申请并敞开连贯，而不须要期待申请实现。411 用于客户端未指定长度的状况，而 413 用于客户端发送的示意太大，以至于服务器无奈解决。客户端能够先做一个 LBYL（look-before-you-leap）申请，免得申请被 413 中断。若 LBYL 申请取得响应代码为 100，客户端再提交残缺的示意。

响应报头：如果因为服务器方面长期遇到问题（比方资源有余），而不是因为客户端方面的问题而导致中断请求的话，服务器能够把 Retry-After 报头的值设为一个日期或一个间隔时间，以秒为单位，以便客户端能够过段时间重试。

• 414(“Request-URI Too Long”)
  重要水平：低。

HTTP 规范并没有对 URI 长度作出官网限度，但大部分现有的 web 服务器都对 URI 长度有一个下限，而 web 服务可能也一样。导致 URI 超长的最常见的起因是：示意数据明明是该放在实体主体里的，但客户端却把它放在了 URI 里。深度嵌套的数据结构也有可能引起 URI 过长。

• 415(“Unsupported Media Type”)
  重要水平：中等。

当客户端在发送示意时采纳了一种服务器无奈了解的媒体类型，服务器发送此响应代码。比如说，服务器冀望的是 XML 格局，而客户端发送的的确 JSON 格局。
如果客户端采纳的媒体类型正确，但格局有问题，这时最好返回更通用的 400。

• 416(“Requestd Range Not Satisfiable”)
  重要水平：低。

当客户端所申请的字节范畴超出示意的理论大小时，服务器发送此响应代码。例如：你申请一个示意的 1 -100 字节，但该示意总共只用 99 字节大小。

申请报头：仅当原始申请里蕴含 Range 报头时，才有可能收到此响应代码。若原始申请提供的是 If-Range 报头，则不会收到此响应代码。
响应报头：服务器该当通过 Content-Range 报头通知客户端示意的理论大小。

• 417(“Expectation Failed”)
  重要水平：中等。

此响应代码跟 100 正好相同。当你用 LBYL 申请来考查服务器是否会承受你的示意时，如果服务器确认会承受你的示意，那么你将取得响应代码 100，否则你将取得 417。

5XX 服务端谬误

这些响应代码表明服务器端呈现谬误。一般来说，这些代码意味着服务器处于不能执行客户端申请的状态，此时客户端应稍后重试。有时，服务器可能预计客户端应在多久之后重试。并把该信息放在 Retry-After 响应报头里。

5XX 系列响应代码在数量上不如 4XX 系列多，这不是因为服务器谬误的几率小，而是因为没有必要如此具体 – 对于服务器方面的问题，客户端是无能为力的。

• 500(“Internal Server Error”)
  重要水平：高。

这是一个通用的服务器谬误响应。对于大多数 web 框架，如果在执行申请解决代码时遇到了异样，它们就发送此响应代码。

• 501(“Not Implemented”)
  重要水平：低。

客户端试图应用一个服务器不反对的 HTTP 个性。
最常见的例子是：客户端试图做一个采纳了拓展 HTTP 办法的申请，而一般 web 服务器不反对此申请。它跟响应代码 405 比拟类似，405 表明客户端所用的办法是一个可辨认的办法，但该资源不反对，而 501 表明服务器基本不能辨认该办法。

• 502(“Bad Gateway”)
  重要水平：低。

只有 HTTP 代理会发送这个响应代码。它表明代理方面呈现问题，或者代理与上行服务器之间呈现问题，而不是上行服务器自身有问题。若代理根本无法拜访上行服务器，响应代码将是 504。

• 503(“Service Unavailable”)
  重要水平：中等到高。

此响应代码表明 HTTP 服务器失常，只是上层 web 服务服务不能失常工作。最可能的起因是资源有余：服务器忽然收到太多申请，以至于无奈全副解决。因为此问题多半由客户端重复发送申请造成，因而 HTTP 服务器能够抉择拒绝接受客户端申请而不是承受它，并发送 503 响应代码。

响应报头：服务器能够通过 Retry-After 报头告知客户端何时能够重试。

• 504(“Gateway Timeout”)
  重要水平：低。

跟 502 相似，只有 HTTP 代理会发送此响应代码。此响应代码表明代理无奈连贯上行服务器。

• 505(“HTTP Version Not Supported”)
  重要水平：非常低。

当服务器不反对客户端试图应用的 HTTP 版本时发送此响应代码。

实体主体：一个形容服务器反对哪些协定的文档。