http状态码详解

http的响应状态码由5段组成

● 1xx，代表消息，一般是告诉客户端，请求已经收到了，正在处理

● 2xx，代表请求处理成功，一般是请求收到、我明白你要的信息、请求已经处理、已经处理完成等信息

● 3xx，代表重定向到其他地方，他让客户端在发起一个请求，以完成整个处理

● 4xx，代表处理发生错误，责任在客户端，如客户端请求一个不存在的资源、客户端未被授权、禁止访问等。

● 5xx、处理发生错误，责任在服务端，如服务端抛出异常，路由出错、HTTP版本不支持等。

以下是http响应状态码的信息表：

一、1xx的解释，消息

A、100：continue，客户端继续发送请求。

这个临时响应，是用来通知客户端，他的部分请求已经被服务器接收，并且未被拒绝。客户端应当接着发送请求的剩余部分；或者如果请求已经完成，则忽略这个响应。服务器必须在请求完成后，向客户端发送一个最终响应。

B、101：switching  protocol，服务器已经理解客户端的请求，并通过Upgrade消息头，通知客户端采用不同的协议来完成请求。

在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似的措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。

C、102：processing，由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

二、2xx的解释，成功

A、200：ok，表示请求已成功，请求所希望的响应头或数据体将随此响应返回。

B、201：created，请求已经被实现。而且有一个新的资源已经依据请求的需要而建立，并且URI已经随location头信息返回。

假如需要的资源无法及时建立的话，应当返回‘202 Accepted’。

C、202：accepted，服务器已经接受请求，但尚未处理。

正如它可能被拒绝一样，最终该请求可能会被执行也可能不会执行。在异步操作的场合下，没有比发送这个状态码更合适的做法了。

返回202状态码的响应的目的是雨荨服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的程序），而不必让客户端一直保持与服务器连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。

D、203：non-authoritative information，服务器已经成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定的集合，而是来自本地或第三方的拷贝。

当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器直到元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 ok的情况下才是合适的。

E、204，no content，服务器成功处理了请求，但不需要返回任何实体内容，但希望返回更新的元信息。

响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。

如果客户端是浏览器的话，那么用户浏览器应该保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息，应当被应用到用户浏览器活动视图中的文档。

由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。

F、205，reset content，服务器成功处理了请求，并且没有返回任何内容。但与204不同，返回此状态码的响应要求请求者重置文档视图。

该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松的开始另一次输入。

与204响应一样，该响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。

G、206，partial content，服务器已经成功处理了部分GET请求。

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

响应必须包含如下的头部域：Content-Range--指示本次响应中返回的内容的范围。如果是Content-Type为multipart/byteranges的多段下载，则每一个multipart段中都应包含Content-Range域用以指示本段的内容范围。

假如，响应中包含Content-Length，那么他的数值必须匹配他返回的内容范围的真实字节数。

H、207，Multi-status，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

三、3xx的解释，重定向

A、300，multiple choices，被请求的资源有一系列可供选择的回馈信息，每个都有自己特定地址和浏览器驱动的上一信息。

用户或浏览器能够自行选择一个首选的地址进行重定向。

除非这是一个HEAD请你去，否则该响应应该包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由Content-Type定义的格式所决定。

浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。

B、301，moved  permanently，被请求的资源已经永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。

如果可能，拥有链接编辑的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可以缓存的。

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

D、303，see  other，对应当请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。

这个方法的存在主要是为了允许脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时303响应进制缓存。当然第二个请求（重定向）可能被缓存。

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

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

G、306，switch proxy，在最新的规范中，306状态已经不再被使用。

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

四、4xx的解释，请求错误

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

B、401，unauthorized，当前请求需要用户验证。

该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头，用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。

四、5xx的解释，服务器错误

详细链接