常见的HTTP状态码

HTTP状态码是服务器和客户端之间交流信息的语言，开发中最常见的状态码有：200、400、500、301、404等，下面详细列出HTTP状态码。
1xx系列
指定客户端相应的某些动作，代表请求已被接受，需要继续处理。由于在HTTP/1.0协议中，没有定义任何1xx系列的状态码，所以除非在某些实验条件下，服务器禁止向此客户端发送1xx系列状态码的响应。

2xx系列
代表请求已成功被服务器接收、理解、并接受。这系列中最常见的有200、201状态码。

200(“OK”)状态码
表示请求已成功，请求需获得的响应头或数据体将随此响应返回。
201(“Created”)状态码
表示请求成功并且服务器创建了新的资源，且其URL已经随location头信息返回，假如需要的资源无法及时建立的话，应当返回【202 Accepted】。
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”)状态码
它跟200类似，但它用于对部分GET请求（即使用Range请求报头的GET请求）的响应。部分GET请求常用于大型二进制文件的断点续传。

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

若实体主体是单个字节范围（byte range），那么HTTP响应里必须包含一个Content-Range报头，以说明本响应返回的是表示的哪个部分，若实体主体是一个多部分实体（multipart entity）（即该实体主体由多个字节范围构成），那么每一个部分都要有自己的Content-Range报头。
实体主体：不是整个表示，而是一个或者多个字节范围。

3xx系列
代表需要客户端采取进一步的操作才能完成请求，它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求，才能得到所需的表示。这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的location域中指明。这系列中最常见的有301、302状态码。
301状态码
被请求的资源已永久移动到新位置。服务器返回此响应（对GET或HEAD请求的响应）时，会自动将请求者转到新位置。
302状态码
请求的资源临时从不同的URL响应请求，但请求者应继续使用原有位置来进行以后的请求。
304状态码
自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应（称为If-Modified-Since HTTP标头）。

4xx系列
表示请求错误，代表了客户端看起来可能发生了错误，妨碍了服务器的处理。不是认证信息有问题，就是表示格式或HTTP库本身有问题。客户端需要自行改正。常见有：400、401、404状态码

400状态码

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

实体主体：可以包含一个错误的描述文档。

401状态码

请求需要身份验证。对于需要登录的网页，服务器可能返回此响应。

403状态码

服务器已经理解请求，但是拒绝执行客户端发送过来的请求。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。

404(“Not Found”)状态码

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

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系列
代表服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见有500、503状态码。

500状态码

服务器遇到了一个未曾预料的状况，导致服务器无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。

503状态码

由于临时的服务器维护或者过载，服务器当前无法处理请求。通常，这个是暂时状态，一段时间会恢复。

504状态码
504状态码代表网关请求超时（Gateway timeout），是指服务器作为网关或代理，但是没有及时从上游服务器接收到请求。