http协议中的状态码

10. 状态码定义
每一个状态码在下面定义，包括此状态码依赖于方法的描述和响应里需要的任何元信息的描
述。
10.1 通知的 1xx
这类状态代码指明了一个临时性的响应，包含一个 Status-Line 和可选的头域，并且被一个空
行结束（译注：空行就是CRLF）。这类状态码响应没有必须的头域。因为HTTP/1.0没有定义
任何 1xx 状态码，所以服务器不能发送一个 1xx 响应给一个 HTTP/1.1 客户端，除了实验性的
目的。
客户端必须能在一个常规响应之前接受一个或多个 1xx 状态，即使客户端不期望 100（继续）
状态响应。不被客户端期望的1xx 状态响应可能会被用户代理忽略。
代理必须能转发 1xx 响应，除非代理和它的客户端的连接关闭了，或者除非代理自己响应请求
并产生1xx 响应。（例如：如果代理添加了“Expect:100-continue”头域当转发请求时，那么它
不必转发相应的100（继续）状态响应。）
10.1.1 100 继续 （Continue）
100 状态响应告诉客户端应该继续请求。100 响应是个中间响应，它被用于通知客户端请求的
初始部分已经被接收了并且此请求还没有被服务器丢弃。客户端应该继续发送请求的剩余部分，
或者，如果此请求已经完成了客户端会忽略此 100 响应。服务器在接收请求后必须发送一个终
结响应。见8.2.3 节关于此状态码的讨论和使用。
10.1.2 101切换协议 （Switching Protocols）
服务器理解和愿意遵循客户端这样的请求，此请求通过 Upgrade 消息头域（见 14.42节）指明
在连接上应用层协议的改变。 服务器将会切换到响应里 Upgrade 头域里指明的协议，它会以
一个空行结束此101 响应。
只有协议切换时能受益协议才应该切换。例如，当传输资源时，切换到一个新的 HTTP 版本比
旧的版本要好，或者切换到一个实时的，同步的协议会带来好处时，这时我们都应该考虑切换。
10.2 成功 2xx
这类状态码指明客户端的请球已经被服务器成功的接收，理解，并且接受了。
10.2.1 200 OK
此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：
GET 请求资源的相应的实体已经包含在响应里并返回给客户端。
HEAD 相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。

POST 响应里已经包含一个实体，此实体描述或者包含此 POST 动作执行的结果

TRACE 响应里包含一个实体，此实体包含终端对服务器接收的请求消息。
10.2.2 201 已创建（Created）
请求已经被服务器满足了并且已经产生了一个新的资源。新创建的资源的 URI 在响应的实体里
返回，但是此资源最精确的URI 是在 Location 头域里给出的。响应应该含有一实体，此实体包
含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被
Content-Type 头域里媒体类型指定。源服务器必须能在返回201状态码之前建立资源。如果动
作（译注：这里指能创建资源的方法，如 POST 方法）不能被立即执行，那么服务器应该以
202（接受）响应代替。
一个 201 响应可以包含一个 ETag 响应头域，此头域的值指明了当前请求变量（译注：变量的
含义见第 1.3 节“变量”的解释）也即刚刚创建的资源的实体标签（entity tag）值，见 14.19
节。
10.2.3 202 接受（Accepted）
请求已经被接受去处理，但是还没有处理完成。请求可能会或者不会处理完成，因为存在当处
理的过程中拒绝处理的情况。
202 响应是有意非担保性的。它是为了允许服务器可以为其它处理（如：每天执行一次的批处
理）接收请求而不需要用户代理在处理没有完成之前长期连接到服务器。响应里的实体应该包
含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估
值。
10.2.4 203 非权威信息（Non-Authoritative information）
此状态码响应指明响应里实体头域元信息不能从源服务器获而是从本地的或第三方响应副本里
收集的。这些元信息可能是源服务器版本的子集或超集。如，包含一个存在本地的资源注释信息
就可以产生一个源服务器能理解的元信息的超集。利用此响应状态码不是必须但是比
200（Ok）响应却更加合适。
10.2.5 204 无内容 （No Content）
服务器已经满足了请求但并没有返回一个实体而是返回更新的元信息。此响应可能包含新的或
更新的元信息以实体头域的形式，这些元信息应该相关于请求变量。
利用此 204 响应，客户端如果是一个用户代理，它就可以不用改变引起请求发送的文档视图
（译注：如一篇 html文档在浏览器里呈现的样子）。204 状态响应主要的目的是允许输入，而
不必引起用户代理当前文档视图的改变，尽管一些新的或更新了的元信息可能会应用于用户代
理视图里的当前文档。
204 响应不能包含一个消息主体，并且在头域后包含一个空行结束。
10.2.6 205 重置内容（Reset Content）
205 状态响应是服务器告诉用户代理应该重置引起请求被发送的文档视图。此响应主要的目的
是清空文档视图表单里的输入框以便用户能输入其它信息。此响应不能包含一个实体。

10.2.7 206 部分内容（Partial Content）
服务器已经完成了客户端对资源的部分 GET 请求。请求必须包含一个 Range头域（14.35 节）
用来指出想要的范围，并且也有可能包含一个 If-Range 头域（见 14.27 节）来使请求成为一个
条件请求。
206 状态的响应必须包含以下的头域：
- 或者含有一个 Content-Range 头域，此头域指明了响应里的范围；或者含有一个值为
“multipart/byteranges”的 Content-Type 头域并且每部分包含 Content-Range 头域。如果一个
Content-Length 头域出现在响应里，它的值必须是实际传输的消息主体的字节数。
- Date 头域
- ETag 和/或 Content-Location 头域，如果这些头域假设在相同请求的 200 响应里也会出现的
话。
- Expire，Cache-Control，和/或者 Vary 头域，如果这些头域的域值与以前同一变量响应中的
不一样。
如果 206 响应是使用了强缓存验证（见 13.3.3）的 If-Range 请求的结果，那么此响应不应该
包含其他的实体头域。如果响应是使用了弱缓存验证的 If-Range 请求的结果，那么响应必须不
能包含其他的实体头域；这能防止缓存里缓存的实体主体与更新头域之间的不一致性。另外，
响应必须包含假设在相同请求的200 响应里的所有实体头域。
缓存不能把 206 响应和以前的缓存内容相合并如果 ETag或 Last-Modified 头域并不能精确匹配，
见13.5.4。
一个不能支持Range 和Content-Range头域的缓存不能缓存206（部分的）响应。
10.3 重新定向 3xx.
这类状态码指明用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动
执行而不需要用户的交互，并且进一步动作请求的方法必须为 GET 或 HEAD。一个客户端应该
发现无限的重定向循环，因为此循环能产生网络拥挤。
注意：以前此规范版本建议一个最多能有五个重定向。内容开发者应该知道客户端可能存在这
个限制。
10.3.1 300 多个选择.（Multiple Choices）
请求资源对应于众多表现形式中的一个，每个表现形式都有一个特定的位置(location)，并且代
理驱动协商（agent-driven negotiation）信息（见 13 章）被提供以便用户（或用户代理）能
选择一个更适的表现形式并重定向它的请求到那个表现形式的位置。
除非是 HEAD 请求，否则 300 状态响应应该包含一个实体，此实体包含一个资源特性和位置
列表，从这个列表里用户或用户代理能选择最合适的资源的表现形式。实体格式被 Content-
Type 头域里的媒体类型指定。用户代理选择最合适的表现形式的行为可能会被自动执行，这依
赖于实体格式和自己的能力。然而，此规范并没有定义自动执行行为的标准。
如果服务器能确定更好的表现形式，它应该为此表现形式在 Location 头域里包含一个特定的

URI 来指明此表现形式的位置；用户代理可能会利用此 Location 头域自动重定向。300 状态响
应是可缓存的除非被特别指明。
10.3.2 301 永久移动 （Moved Permanently）
请求资源被赋于一个新的永久的 URI，并且任何将来对此资源的引用都会利用此 301 状态响应
返回的 URI。具有链接编辑能力的客户端应该能自动把请求 URI 的引用转到到服务器返回的新
的引用下。此响应是能缓存的除非另外声明。
新的永久URI 应该在响应中被 Location 头域给定。除非请求方法是 HEAD，否则此响应应该包
含一个超文本提示和一个指向新URI 的超文本链接。
如果客户端接收了一个来自非 GET 或 HEAD 请求方法的 301 响应，那么用户代理不能自动重
定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。
注意：当客户端在接收了 301 状态码响应后，会重定向 POST 请求，一些已经存在的
HTTP/1.0 用户代理会错误的把此请求变成一个GET请求。
10.3.3 302 发现(Found)
请求的资源暂时地存放在一个不同的 URI 下。因为重定向的地址可能有时会被改变，客户端应
该继续为将来的请求利用请求URI(Request-URI)。302响应是只有在 Cache-Control 或 Expires
头域指明的情况下才能被缓存。
临时的URI 应该在 Location 头域里指定。除非请求方法是 HEAD，否则此响应应该包含一个超
文本提示和一个指向新URI 的超文本链接。
如果客户端接收了一个来自非 GET 或 HEAD 请求方法的 302 响应，那么用户代理不能自动重
定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。
注意：RFC1945和 RFC2068 指定客户端不能在重定向请求的时候改变请求方法。然而，大多
数用户代理实现会把 302 响应看成是 303 响应，从而根据 Location 头域值的 URI 执行 GET 请
求，不管原始的请求方法是什么。303 和 307 状态响应的目的是为使服务器明白客户端期望哪
种类型的重定向。
10.3.4 303 见其他(See Other)
请求的响应被放在一个不同的URI 下，并且应该用 GET 方法获得那个资源。此方法的存在主要
是让POST 调用脚本的输出能使用户代理重定向到一个选择的资源。新的 URI 并不是原始请求
资源的代替引用。303 响应不能被缓存，但是再次重定向请求的响应应该被缓存。
不同的URI 应该在 Location 头域里指定。除非请求方法是 HEAD，除非请求方法是 HEAD，否
则此响应应该包含一个超文本提示和一个指向新 URI 的超文本链接。
注意：许多 HTTP/1.1 以前版本的用户代理不能理解 303 状态响应。当这些客户端比较关注于
互操作性的时候，302 状态码应该被代替利用，因为大多用户代理对 302 响应的理解就是 303
响应。
10.3.5 304 没有改变（Not Modified）

如果客户端已经执行了条件 GET 请求，并且访问服务器的资源是允许的，但是服务器上的文
档并没有被改变，那么服务器应该以此状态码响应。304响应不能包含一个消息主体(message-
body)，并且在头域后面总是以一个空行结束。
此响应必须包含下面的头域：
- Date，除非 14.18.1 指明的那些规则下 Date是可以遗漏的。如果时钟不准确的源服务器遵循
这些规则，并且代理和客户端在接收了一个没有 Date 头域的响应后加上了自己的 Date（这在
RFC 2086 里声明了，见14.19节），缓存将会正确操作。
- ETag 和/或 Content-Location 头域，如果这些头域应在相同请求的 200 响应里出现的话。
- Expire，Cache-Control，和/或者 Vary 头域，如果这些头域值与以前同一变量响应中的不一
致。
如果条件GET 请求使用强缓存验证（见 13.3.3 节）时，那么响应不应包含其它实体头域。当条
件 GET 使用弱缓存验证时，那么响应必须不能包含其它实体头域；这能防止缓存的实体主体
与更新的头域之间的不一致性。
如果一个 304响应指示一个没有被缓存的实体，那么此缓存必须不用理会此响应，并且以无条
件请求重试请求。
如果缓存利用一个接收到的 304响应去更新一个缓存项，那么缓存必须用此响应响应里任何最
新的域值更新缓存项。
10.3.6 305 使用代理 （Use Proxy）
请求资源必须能通过代理访问，代理的地址在响应的 Location 头域里指定。Location 头域指定了
代理的URI。接收者被期望通过代理重试此请求，305 响应必须被源服务器产生。
注意：RFC 2068 并没有说明 305响应必须重定向一个单独请求并且只能被源服务器产生。不注
意这些限制会有重要的安全后果。
10.3.7 306没有使用的（unused）
306 状态码被用于此规范以前的版本，是不再使用的意思，并且此状态码被保留。
10.3.8 307临时重发（Temporary Redirect）
请求的资源临时存在于一个不同的 URI下。由于重新向可能有时会改变，所以客户端应该继续
利用此请求URI（Request-URI）为将来的请求。307 响应只有被 Cache-Control或Expire头域
指明时才能被缓存。
临时URI 应该在响应的 Location 头域里给定。否则此响应应该包含一个超文本提示和一个指向
新 URI 的超文本链接，因为许多 HTTP/1.1 以前的用户代理不能理解 307 状态响应。因此，此
提示应该包含用户在新的URI 上重试原始请求的必需信息。
如果 307 状态响应.对应的请求的方法不是 GET 或 HEAD，那么用户代理不能自动重定向此请
求除非它能被用户确认，因为因为这可能会改变请求提交的条件。

10.4 客户端错误 4xx
状态码 4xx类的目的是为了指明客户端出现错误的情况。除了当响应一个 HEAD 请求，服务器
应该包含一个实体，此实体包含一个此错误请求的解释。此状态码对所有请求方法都是适合的。
用户代理应该展示任何响应里包含的实体给用户。
如果客户端发送数据，利用 TCP 的服务器实现应该小心地确保客户端确认包含了响应的包
（packets）的接收，在服务器关闭此输入连接前。如果在关闭连接后，客户端继续发送数据给
服务器，那么服务器的 TCP 栈将发送一个重置包给客户端，这能擦除客户端非确认的输入缓
冲（input buffers）在这些缓冲被 HTTP应用程序读和解析之前。
10.4.1 400 坏请求（Bad Request）
请求不能被服务器理解，由于错误的语法。客户端不应该在没有改变请求的情况下重试请求。
10.4.2 401 未授权的 （Unauthorized）
服务器需要对请求进行用户认证。响应必须包含一个 WWW-Authenticate 头域（见 14.47），
此头域包含一个适用于请求资源的授权的激励（challenge）。客户端会以一个Authorization 头
域重试请求。如果请求包含了授权证书，那么 401响应指明对这些证书的授权失败。如果 401响
应包含一个和以前响应的同样激励，并且用户代理已经尝试至少一次的授权，那么用户应该被
呈现包含在响应里的实体，因为这些实体可能包含相关的诊断信息。HTTP授权访问在“HTTP
Authentication：Basic and Digest Access Authentication”[43]里解释。
10.4.3 402 必需的支付 （Payment Required）
此状态码为将来的应用保留。
10.4.4 403 禁用 （Forbidden）
服务器理解此请求，但拒绝满足此请求。认证是没有作用的，并且请求不应该被重试。如果请求
方法是 HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实
体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么 404 状态码(Not
Found)响应将被使用。
10.4.5 404 没有找到（Not Found）
服务器并没有找到任何可以匹配请求 URI 的资源。没有迹象表明条件是暂时或永久的 。
410（Gone）状态响应应该被使用，如果服务器通过内部配置机制知道一个旧资源永远不能获
得并且也没有转发地址。此状态码通常被使用，当服务器不希望精确指出请求为何被拒绝，或
者当没有任何其它响应可用时。
10.4.6 405 方法不被允许（Method Not Allowed）
此状态码表示请求行（Request-Line）里的方法对此资源来说不被允许。响应必须包含一个
Allow 头域，此头域包含以一系列对此请求资源有效的方法。

10.4.7 406 不可接受的 （Not Acceptable）
根据客户端请求的接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, 或者 Accept-
Language），服务器不能产生让客户端可以接受的响应。
除非是 HEAD请求，否则响应应该包含一个实体，此实体应该包含一个可得的实体特性和位置
列表，通过它用户或用户代理能选择最合适自己的。实体格式被媒体类型指定。依赖于此格式和
用户代理的本身能力，选择最合适的可能会被自动执行。然而，此规范并没有定义自动执行选
择的标准。
注意：HTTP/1.1服务器被准许根据请求里的接受头域会返回不可接受的响应。在一些情况下，
这可能更倾向于发送一个406响应。用户代理被鼓励观察到来的响应的头域来确定此响应是否是
可接受的。
如果响应是不可接受的，用户代理应该暂时停止剩余数据的接收并且询问用户然后去决定进一
步的动作。
10.4.8 407 需要代理验证（Proxy Authentication Required）
此状态码和 401（Unauthorized）相似，但是指示客户端首先必须利用代理对自己验证。代理必
须返回一个 Proxy-Authenticate 头域（见 14.33 节），此头域包含一个适用于代理的授权激励。
客户端可能利用一个合适的Proxy-Autorization 头域去重试此请求（见 14.34节）。HTTP访问授
权在“HTTP Authentication；Basic and Digest Access Authentication”[43]。
10.4.9 408 请求超时（Request Timeout）
客户端在服务器等待的时间里不能产生请求。客户端可能在以后会重试此请求。
10.4.10 409 冲突 （Confilict）
请求不能完成由于和当前资源的状态冲突。此状态码只被允许出现在期望用户也许能解决此冲
并且能重新提交此请求的情况下。响应主体应该包含足够的为用户认识此资源冲突的信息。理想
的情况下，响应实体应该包含足够为用户或用户代理解决此问题的信息；然而，这是也许没有
可能并且也没有必要。
冲突最可能发生在响应 PUT 请求的时候。例如，如果版本被使用并且被 PUT 的实体包含资源
的改变，而这些改变会和以前的（第三方的）请求的相冲突，那么服务器应该使用 409响应去
指明它不能完成此请求。在这种情况下，此响应的实体可能包含这两个版本的差异点，响应的
实体格式以Content-Type 头域指定。
10.4.11 410 不存在（gone）
请求资源在源服务器上不再可得并且也没有转发地址可用。此条件被认为是永久的。具有链接编
辑能力的客户端应该在用户确认后删除请求 URI的引用。如果服务器不知道或不容易去确定条
件是否是永久的，那么此404（没有发现）状态响应将被代替利用。响应是可缓存的，除非另外
申明。
410 响应主要的目的是为了 web 维护任务，这通过告诉接收者资源已经不可得了并且告诉接收
者服务器拥有者已经把那个资源的远程连接给移除了。对有时间限制的，推销性的服务，和对
不再继续工作在服务器站点人员的资源，这个事件（410 响应）是非常普遍的。它不需要把所有

长久不可得的资源标记为“gone”或者保持任意长时间—这需要服务器拥有者自己的判断
10.4.12 411 长度必需 （Length Required）
服务器拒绝接受请求里没有包含Content-Length 头域的请求。客户端可以重试此请求如果它添
加了一个有效的Content-Length 头域，此头域值指定了请求消息里消息主体的长度。
10.4.13 412 先决条件失败 （Precondition Failed）
在一个或多个请求头域里指定的先决条件当在服务器上测试为 false 时返回的响应。此响应允许
客户端把先决条件放放到当前资源的元信息（头域数据）之上，这样能防止请求方法被应用于
一个非目的性的资源。
10.4.14 413 请求实体太大
服务器拒绝处理请求因为请求实体太大以致达到服务器不愿意去处理。服务器可能关闭此连接
去防止客户端继续请求。
如果条件是暂时的，服务器应该包含一个 Retry-After 头域用来指明此条件是暂时的并且指明客
户端应该什么时候重试。
10.4.15 414 请求URI 太长（Request-URI Too Long）
服务器拒绝为请求服务因为此请求 URI太长了以至于服务器不能解析。这种情况是很少的，只
发生在当客户端把POST 请求不合适地转换为带有大量查询信息的 GET 请求时。
10.4.16 415 不被支持的媒体类型（Unsupported Media Type）
服务器拒绝为请求服务，因为请求的实体的格式不能被此方法的请求资源所支持。
10.4.17 416 请求范围不满足 （Requested Range Not Satisfiable）
服务器返回一个此状态码的响应，如果请求包含一个 Range 请求头域（见 14.35 节），并且
此头域里 range-specifier 值没有和已选资源的当前 extent 值重叠，并且请求没有包含一个 If-
Range 请求头域。（对 byte-ranges来说，这意味着 byte-range-spec 的所有 first-byte-pos
值大于选择的资源的当前长度）。
当此状态码响应是在 byte-range 请求返回时，响应应该包含一个 Content-Range 实体头域用
来指定已选资源的当前长度（见14.16 节）。响应不能使用 multipart/byteranges 媒体类型。
10.4.18 417 期望失败（Expectation Failed）
Expect 请求头域里指定的希望不能被服务器满足，或者，如果服务器是代理，那么能确定请
求不能被下一站（next-hop）服务器满足。

10.5 服务器错误 5xx （Server Error）
这类状态码指明服务器处理请求时产生错误或不能处理请求。除了 HEAD 请求，服务器应该包
含一个实体，此实体用来解释错误，和是否是暂时或长期条件。用户代理应该展示实体给用户。
此响应状态码能应用于任何请求方法。
10.5.1 500 服务器内部错误 （Internal Server Error）
服务器遇到了一个意外条件，此条件防止服务器满足此请求。
10.5.2 501 不能实现 （Not Implemented）
服务器没有能力去满足请求。当服务器不能识别请求方法并且不支持它请求资源的时候，这个
响应是很合适的。
10.5.3 502 坏网关 （Bad Gateway）
此响应说明：作为网关或代理的服务器从上游（upstream）服务器接收了一个无效的响应。
10.5.4 503 服务不能获得（Service Unavailable）
由于服务器暂时地过载或维护，服务器不能处理请求。这就是说这是暂时条件，此条件将会在
一些延时后被减轻。延迟的长度可以在 Retry-After 头域里指定。如果没有Retry-After 被给，那
么客户端应该处理此响应就像它处理 500 响应一样。
注意：503 状态码的存在并不是意指服务器当产生过载时必须利用它。一些服务器可能希望拒
绝此连接。
10.5.5 504 网关超时（Gateway Timeout）
作为网关或代理的服务器在不能及时地接收一个从 URI 指定的上游（upstream）服务器（例
如：HTTP，FTP，LDAP服务器）或者其他的辅助性服务器（例如：DNS 服务器）的响应。
注意：当DNS 查找超时时，一些部署的代理将会返回 400或500 响应。
10.5.6 505 HTTP 版本不支持 （HTTP version Not Supported）
服务器不能支持，或拒绝支持此 HTTP 协议版本消息。505 响应指明服务器不能或不愿意完成
这样的请求，这在 3.1 中描述了。此响应应该包含一个实体，此实体描述了为什么此协议版本
不被支持和其他能被服务器支持的协议版本