HTTP 协议状态码含义
HTTP协议中状态码的含义
当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。
HTTP状态码的英文为HTTP Status Code。 下面是常见的HTTP状态码：
- 200 - 请求成功
- 301 - 资源（网页等）被永久转移到其它URL
- 404 - 请求的资源（网页等）不存在
- 500 - 内部服务器错误
HTTP状态码的分类
HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
10.状态码定义
每一个状态码在下面定义，包括此状态码依赖于方法的描述和响应里需要的任何元信息的描述。10.1 通知的 1xx
这类状态代码指明了一个临时性的响应，包含一个Status-Line和可选的头域，并且被一个空行结束（空行就是CRLF）。这类状态码响应没有必须的头域。因为HTTP/1.0没有定义任何1xx状态码，所以服务器不能发送一个1xx响应给一个HTTP/1.1客户端，除了实验性的目的。
客户端必须能在一个常规响应之前接受一个或多个1xx状态，即使客户端不期望100（继续）状态响应。不被客户端期望的1xx状态响应可能会被用户代理忽略。代理必须能转发1xx响应，除非代理和它的客户端的连接关闭了，或者除非代理自己响应请求并产生1xx响应。（例如：如果代理添加了“Expect:100-continue”头域当转发请求时，那么它
不必转发相应的100（继续）状态响应。）
100状态响应告诉客户端应该继续请求。100响应是个中间响应，它被用于通知客户端请求的初始部分已经被接收了并且此请求还没有被服务器丢弃。客户端应该继续发送请求的剩余部分，或者，如果此请求已经完成了客户端会忽略此100响应。服务器在接收请求后必须发送一个终结响应。
服务器理解和愿意遵循客户端这样的请求，此请求通过Upgrade消息头域指明在连接上应用层协议的改变。 服务器将会切换到响应里Upgrade头域里指明的协议，它会以一个空行结束此101响应。只有协议切换时能受益协议才应该切换。例如，当传输资源时，切换到一个新的HTTP版本比旧的版本要好，或者切换到一个实时的，同步的协议会带来好处时，这时我们都应该考虑切换。
这类状态码指明客户端的请球已经被服务器成功的接收，理解，并且接受了。
此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：
GET 请求资源的相应的实体已经包含在响应里并返回给客户端。
HEAD 相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。
POST 响应里已经包含一个实体，此实体描述或者包含此POST动作执行的结果
TRACE 响应里包含一个实体，此实体包含终端对服务器接收的请求消息。
请求已经被服务器满足了并且已经产生了一个新的资源。新创建的资源的URI在响应的实体里返回，但是此资源最精确的URI是在Location头域里给出的。响应应该含有一实体，此实体包含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被Content-Type头域里媒体类型指定。源服务器必须能在返回201状态码之前建立资源。如果动作（译注：这里指能创建资源的方法，如POST方法）不能被立即执行，那么服务器应该以
202（接受）响应代替。一个201响应可以包含一个ETag响应头域，此头域的值指明了当前请求变量，也即刚刚创建的资源的实体标签（entity tag）值。
请求已经被接受去处理，但是还没有处理完成。请求可能会或者不会处理完成，因为存在当处理的过程中拒绝处理的情况。202响应是有意非担保性的。它是为了允许服务器可以为其它处理（如：每天执行一次的批处理）接收请求而不需要用户代理在处理没有完成之前长期连接到服务器。响应里的实体应该包含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估值。
此状态码响应指明响应里实体头域元信息不能从源服务器获而是从本地的或第三方响应副本里收集的。这些元信息可能是源服务器版本的子集或超集。如，包含一个存在本地的资源注释信息就可以产生一个源服务器能理解的元信息的超集。利用此响应状态码不是必须但是比200（Ok）响应却更加合适。
服务器已经满足了请求但并没有返回一个实体而是返回更新的元信息。此响应可能包含新的或更新的元信息以实体头域的形式，这些元信息应该相关于请求变量。利用此204响应，客户端如果是一个用户代理，它就可以不用改变引起请求发送的文档视图。204状态响应主要的目的是允许输入，而不必引起用户代理当前文档视图的改变，尽管一些新的或更新了的元信息可能会应用于用户代理视图里的当前文档。204响应不能包含一个消息主体，并且在头域后包含一个空行结束。
205状态响应是服务器告诉用户代理应该重置引起请求被发送的文档视图。此响应主要的目的是清空文档视图表单里的输入框以便用户能输入其它信息。此响应不能包含一个实体。
服务器已经完成了客户端对资源的部分GET请求。请求必须包含一个Range头域用来指出想要的范围，并且也有可能包含一个If-Range头域来使请求成为一个条件请求。
206状态的响应必须包含以下的头域：
- 或者含有一个Content-Range 头域，此头域指明了响应里的范围；或者含有一个值为“multipart/byteranges”的Content-Type头域并且每部分包含Content-Range头域。如果一个Content-Length头域出现在响应里，它的值必须是实际传输的消息主体的字节数。
- Date头域
- ETag 和/或 Content-Location头域，如果这些头域假设在相同请求的200响应里也会出现的话。
- Expire，Cache-Control，和/或者Vary头域，如果这些头域的域值与以前同一变量响应中的不一样。
如果206响应是使用了强缓存验证的If-Range请求的结果，那么此响应不应该包含其他的实体头域。如果响应是使用了弱缓存验证的If-Range请求的结果，那么响应必须不能包含其他的实体头域；这能防止缓存里缓存的实体主体与更新头域之间的不一致性。另外，响应必须包含假设在相同请求的200响应里的所有实体头域。缓存不能把206响应和以前的缓存内容相合并如果ETag或Last-Modified头域并不能精确匹配。一个不能支持Range和Content-Range头域的缓存不能缓存206（部分的）响应。
这类状态码指明用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动执行而不需要用户的交互，并且进一步动作请求的方法必须为GET或HEAD。一个客户端应该发现无限的重定向循环，因为此循环能产生网络拥挤。注意：以前此规范版本建议一个最多能有五个重定向。内容开发者应该知道客户端可能存在这个限制。
请求资源对应于众多表现形式中的一个，每个表现形式都有一个特定的位置(location)，并且代理驱动协商（agent-driven negotiation）信息被提供以便用户（或用户代理）能选择一个更适的表现形式并重定向它的请求那个表现形式的位置。除非是HEAD请求，否则300状态响应应该包含一个实体，此实体包含一个资源特性和位置列表，从这个列表里用户或用户代理能选择最合适的资源的表现形式。实体格式被Content-Type头域里的媒体类型指定。用户代理选择最合适的表现形式的行为可能会被自动执行，这依赖于实体格式和自己的能力。然而，此规范并没有定义自动执行行为的标准。如果服务器能确定更好的表现形式，它应该为此表现形式在Location头域里包含一个特定的
URI来指明此表现形式的位置；用户代理可能会利用此Location头域自动重定向。300状态响应是可缓存的除非被特别指明。
请求资源被赋于一个新的永久的URI，并且任何将来对此资源的引用都会利用此301状态响应返回的URI。具有链接编辑能力的客户端应该能自动把请求URI的引用转到到服务器返回的新的引用下。此响应是能缓存的除非另外声明。新的永久URI应该在响应中被Location头域给定。除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。如果客户端接收了一个来自非GET或HEAD请求方法的301响应，那么用户代理不能自动重定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。
注意：当客户端在接收了301 状态码响应后，会重定向POST 请求，一些已经存在的HTTP/1.0用户代理会错误的把此请求变成一个GET请求。
请求的资源暂时地存放在一个不同的URI下。因为重定向的地址可能有时会被改变，客户端应该继续为将来的请求利用请求URI(Request-URI)。302响应是只有在Cache-Control或Expires头域指明的情况下才能被缓存。临时的URI应该在Location头域里指定。除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。如果客户端接收了一个来自非GET或HEAD请求方法的302响应，那么用户代理不能自动重定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。
注意：RFC1945和RFC2068指定客户端不能在重定向请求的时候改变请求方法。然而，大多数用户代理实现会把302响应看成是303响应，从而根据Location头域值的URI执行GET请求，不管原始的请求方法是什么。303和307状态响应的目的是为使服务器明白客户端期望哪种类型的重定向。
请求的响应被放在一个不同的URI下，并且应该用GET方法获得那个资源。此方法的存在主要是让POST调用脚本的输出能使用户代理重定向到一个选择的资源。新的URI并不是原始请求资源的代替引用。303响应不能被缓存，但是再次重定向请求的响应应该被缓存。不同的URI应该在Location头域里指定。除非请求方法是HEAD，除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。
注意：许多HTTP/1.1以前版本的用户代理不能理解303状态响应。当这些客户端比较关注于互操作性的时候，302状态码应该被代替利用，因为大多用户代理对302响应的理解就是303响应。
如果客户端已经执行了条件GET请求，并且访问服务器的资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该以此状态码响应。304响应不能包含一个消息主体(messagebody)，并且在头域后面总是以一个空行结束。此响应必须包含下面的头域：
- Date，除非指明的那些规则下Date是可以遗漏的。如果时钟不准确的源服务器遵循这些规则，并且代理和客户端在接收了一个没有Date头域的响应后加上了自己的Date，缓存将会正确操作。
- ETag 和/或 Content-Location头域，如果这些头域应在相同请求的200响应里出现的话。
- Expire，Cache-Control，和/或者Vary头域，如果这些头域值与以前同一变量响应中的不一致。
如果条件GET请求使用强缓存验证时，那么响应不应包含其它实体头域。当条件GET使用弱缓存验证时，那么响应必须不能包含其它实体头域；这能防止缓存的实体主体与更新的头域之间的不一致性。如果一个304响应指示一个没有被缓存的实体，那么此缓存必须不用理会此响应，并且以无条件请求重试请求。如果缓存利用一个接收到的304响应去更新一个缓存项，那么缓存必须用此响应响应里任何最新的域值更新缓存项。
请求资源必须能通过代理访问，代理的地址在响应的Location头域里指定。Location头域指定了代理的URI。接收者被期望通过代理重试此请求，305响应必须被源服务器产生。
注意：RFC 2068并没有说明305响应必须重定向一个单独请求并且只能被源服务器产生。不注意这些限制会有重要的安全后果。
306状态码被用于此规范以前的版本，是不再使用的意思，并且此状态码被保留。
请求的资源临时存在于一个不同的URI下。由于重新向可能有时会改变，所以客户端应该继续利用此请URI（Request-URI）为将来的请求。307响应只有被Cache-Control或Expire头域指明时才能被缓存。临时URI应该在响应的Location头域里给定。否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接，因为许多HTTP/1.1以前的用户代理不能理解307状态响应。因此，此提示应该包含用户在新的URI上重试原始请求的必需信息。如果307状态响应.对应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向此请求除非它能被用户确认，因为因为这可能会改变请求提交的条件。
状态码4xx类的目的是为了指明客户端出现错误的情况。除了当响应一个HEAD请求，服务器应该包含一个实体，此实体包含一个此错误请求的解释。此状态码对所有请求方法都是适合的。用户代理应该展示任何响应里包含的实体给用户。如果客户端发送数据，利用TCP的服务器实现应该小心地确保客户端确认包含了响应的包（packets）的接收，在服务器关闭此输入连接前。如果在关闭连接后，客户端继续发送数据给服务器，那么服务器的TCP栈将发送一个重置包给客户端，这能擦除客户端非确认的输入缓冲（input buffers）在这些缓冲被HTTP应用程序读和解析之前。
请求不能被服务器理解，由于错误的语法。客户端不应该在没有改变请求的情况下重试请求。
服务器需要对请求进行用户认证。响应必须包含一个WWW-Authenticate头域，此头域包含一个适用于请求资源的授权的激励（challenge）。客户端会以一个Authorization头域重试请求。如果请求包含了授权证书，那么401响应指明对这些证书的授权失败。如果401响应包含一个和以前响应的同样激励，并且用户代理已经尝试至少一次的授权，那么用户应该被呈现包含在响应里的实体，因为这些实体可能包含相关的诊断信息。
此状态码为将来的应用保留。
服务器理解此请求，但拒绝满足此请求。认证是没有作用的，并且请求不应该被重试。如果请求方法是HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么404 状态码(NotFound)响应将被使用。
服务器并没有找到任何可以匹配请求URI 的资源。没有迹象表明条件是暂时或永久的。
410（Gone）状态响应应该被使用，如果服务器通过内部配置机制知道一个旧资源永远不能获得并且也没有转发地址。此状态码通常被使用，当服务器不希望精确指出请求为何被拒绝，或
者当没有任何其它响应可用时。
此状态码表示请求行（Request-Line）里的方法对此资源来说不被允许。响应必须包含一个
Allow头域，此头域包含以一系列对此请求资源有效的方法。
根据客户端请求的接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, 或者 Accept-Language），服务器不能产生让客户端可以接受的响应。除非是HEAD请求，否则响应应该包含一个实体，此实体应该包含一个可得的实体特性和位置列表，通过它用户或用户代理能选择最合适自己的。实体格式被媒体类型指定。依赖于此格式和用户代理的本身能力，选择最合适的可能会被自动执行。然而，此规范并没有定义自动执行选择的标准。
注意：HTTP/1.1服务器被准许根据请求里的接受头域会返回不可接受的响应。在一些情况下，这可能更倾向于发送一个406响应。用户代理被鼓励观察到来的响应的头域来确定此响应是否是可接受的。如果响应是不可接受的，用户代理应该暂时停止剩余数据的接收并且询问用户然后去决定进一步的动作。
此状态码和401（Unauthorized）相似，但是指示客户端首先必须利用代理对自己验证。代理必须返回一个Proxy-Authenticate头域，此头域包含一个适用于代理的授权激励。客户端可能利用一个合适的Proxy-Autorization头域去重试此请求。
客户端在服务器等待的时间里不能产生请求。客户端可能在以后会重试此请求。
请求不能完成由于和当前资源的状态冲突。此状态码只被允许出现在期望用户也许能解决此冲并且能重新提交此请求的情况下。响应主体应该包含足够的为用户认识此资源冲突的信息。理想的情况下，响应实体应该包含足够为用户或用户代理解决此问题的信息；然而，这是也许没有可能并且也没有必要。冲突最可能发生在响应PUT请求的时候。例如，如果版本被使用并且被PUT的实体包含资源的改变，而这些改变会和以前的（第三方的）请求的相冲突，那么服务器应该使用409响应去指明它不能完成此请求。在这种情况下，此响应的实体可能包含这两个版本的差异点，响应的实体格式以Content-Type头域指定。
请求资源在源服务器上不再可得并且也没有转发地址可用。此条件被认为是永久的。具有链接编辑能力的客户端应该在用户确认后删除请求URI的引用。如果服务器不知道或不容易去确定条件是否是永久的，那么此404（没有发现）状态响应将被代替利用。响应是可缓存的，除非另外申明。
410响应主要的目的是为了web维护任务，这通过告诉接收者资源已经不可得了并且告诉接收者服务器拥有者已经把那个资源的远程连接给移除了。对有时间限制的，推销性的服务，和对不再继续工作在服务器站点人员的资源，这个事件（410响应）是非常普遍的。它不需要把所有长久不可得的资源标记为“gone”或者保持任意长时间—这需要服务器拥有者自己的判断
服务器拒绝接受请求里没有包含Content-Length头域的请求。客户端可以重试此请求如果它添加了一个有效的Content-Length头域，此头域值指定了请求消息里消息主体的长度。
在一个或多个请求头域里指定的先决条件当在服务器上测试为false时返回的响应。此响应允许客户端把先决条件放放到当前资源的元信息（头域数据）之上，这样能防止请求方法被应用于一个非目的性的资源。
服务器拒绝处理请求因为请求实体太大以致达到服务器不愿意去处理。服务器可能关闭此连接去防止客户端继续请求。如果条件是暂时的，服务器应该包含一个Retry-After头域用来指明此条件是暂时的并且指明客户端应该什么时候重试。
服务器拒绝为请求服务因为此请求URI太长了以至于服务器不能解析。这种情况是很少的，只发生在当客户端POST请求不合适地转换为带有大量查询信息的GET请求时。
服务器拒绝为请求服务，因为请求的实体的格式不能被此方法的请求资源所支持。
服务器返回一个此状态码的响应，如果请求包含一个Range请求头域，并且此头域里range-specifier值没有和已选资源的当前extent值重叠，并且请求没有包含一个If-Range请求头域。（对byte-ranges来说，这意味着byte-range-spec的所有first-byte-pos值大于选择的资源的当前长度）。当此状态码响应是在byte-range请求返回时，响应应该包含一个Content-Range实体头域用来指定已选资源的当前长度。响应不能使用multipart/byteranges媒体类型。
Expect请求头域里指定的希望不能被服务器满足，或者，如果服务器是代理，那么能确定请求不能被下一站（next-hop）服务器满足。
这类状态码指明服务器处理请求时产生错误或不能处理请求。除了HEAD请求，服务器应该包含一个实体，此实体用来解释错误，和是否是暂时或长期条件。用户代理应该展示实体给用户。此响应状态码能应用于任何请求方法。
服务器遇到了一个意外条件，此条件防止服务器满足此请求。
服务器没有能力去满足请求。当服务器不能识别请求方法并且不支持它请求资源的时候，这个响应是很合适的。
此响应说明：作为网关或代理的服务器从上游（upstream）服务器接收了一个无效的响应。
由于服务器暂时地过载或维护，服务器不能处理请求。这就是说这是暂时条件，此条件将会在一些延时后被减轻。延迟的长度可以在Retry-After头域里指定。如果没有Retry-After被给，那么客户端应该处理此响应就像它处理500响应一样。
注意：503状态码的存在并不是意指服务器当产生过载时必须利用它。一些服务器可能希望拒绝此连接。
作为网关或代理的服务器在不能及时地接收一个从URI指定的上游（upstream）服务器（例如：HTTP，FTP，LDAP服务器）或者其他的辅助性服务器（例如：DNS服务器）的响应。
注意：当DNS查找超时时，一些部署的代理将会返回400或500响应。
服务器不能支持，或拒绝支持此HTTP协议版本消息。505响应指明服务器不能或不愿意完成这样的请求。此响应应该包含一个实体，此实体描述了为什么此协议版本不被支持和其他能被服务器支持的协议版本。
