http 状态码

每一个状态码在下面定义，包括此状态码依赖于方法的描述和响应里需要的任何元信息的描述。

通知的 1xx
这类状态代码指明了一个备用的响应，包含一个Status-Line和可选的头域，并且一一个空行结束（译注：空行就是CRLF）。没有必须的头域对这类状态码。因为HTTP/1.0没有定义任何1xx状态码，所以服务器不能发送一个1xx响应给一个HTTP/1.1客户端，除了实验性的目的。

客户端必须能准备去接受一个或多个1xx状态响应优先于一个常规响应，即使客户端不期望100（继续）状态响应。不被客户端期望的1xx状态响应可能会被用户代理忽略。

代理服务器必须能转发1xx响应，除非代理服务器和它的客户端的连接关闭了，或者除非代理服务器自己响应请求并产生1xx响应。（例如：如果代理服务器添加了”Expect:100-continue”头域当转发请求时，那么它不必转发相应的100（继续）响应。）

100 继续 （Continue）
100状态响应告诉客户端应该继续请求。100响应是个中间响应，它被用于通知客户端请求的初始部分已经被接收了并且此请求还没有被服务器丢弃。客户端应该继续发送请求的剩余部分，或者如果此请求已经完成了，客户端会忽略此100响应。服务器必须发送一个final响应在请求接收后。见8.2.3节关于此状态码的讨论和使用。

101切换协议 （Switching Protocols）
服务器理解和愿意遵循客户端这样的请求，此请求通过Upgrade消息头域（见14.42节）指明在连接上应用层协议的改变。 服务器将会切换到响应里Upgrade头域里指明的协议，然后紧接着跟随一个结束此101响应的空行。

只有当协议切换时能受益，协议才应该切换。例如，当传输资源时，切换到一个新的HTTP版本比旧的版本要好，或者切换到一个实时的，同步的协议带来好处时，我们都应该考虑切换。

成功 2xx
这类状态码指明客户端的请球已经被服务器成功的接收了，理解了，并且接受了。

200 OK
此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：

GET      请求资源的相应的实体已经包含在响应里并返回给客户端。

HEAD     相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。

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

TRACE    响应里包含一个实体，此实体包含终端对服务器接的请求消息。

201 已创建（Created）
请求已经被服务器满足了并且已经产生了一个新的资源。新创建的资源的URI在响应的实体里返回，但是此资源最确定的URI是在Location头域里给出的。响应应该含有一实体，此实体包含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被Content-Type头域里媒体类型指定。源服务器必须能在返回201状态码之前建立资源。如果动作（译注：这里指能创建资源的方法，如POST方法）不能被立即执行，那么服务器应该以202（接受）响应代替。

一个201响应可以包含一个ETag响应头域，此头域为请求的变量（译注：变量的含义见第1.3节“变量”的解释）指明当前的实体标签（entity tag）值，当资源被创建时，见14.19节。

202 接受（Accepted）
请求已经被接受了，但是还没有对此请求处理完。请求可能处理完也可能没有最终被处理完，因为当处理发生的时候服务器可能会发现此请求不能被处理。

202响应是非委托的。这是为了允许服务器为其他处理（如：每天执行一次的过程）而接受一个请求从而不需要用户代理和服务器之间在处理完成之前必须进行持久连接。响应里的实体应该包含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估。

203 非权威信息（Non-Authoritative information）
此状态码响应指明响应里的实体头域里的元信息对源服务器来说是没有意义的，这些元信息是从局部的或第三方的响应副本里得到的。这些元信息可能是源服务器版本的子集或超集。如，包含一个存在本地的资源注释信息就可以产生一个源服务器能理解的元信息的超集。203响应状态码的使用并不是必须的并且只有在响应是非200（Ok）响应时才是合适的。

204 无内容 （No Content）
服务器已经满足了请求但不需要返回一个实体，并且可能只想返回更新了的元信息。204状态响应可能包含一个新的或更新了的，和请求变量（译注：变量是资源的一种表现形式，这和rest架构里的定义是一样的，所以这里我们可以理解请求变量是请求资源的一种表现形式）相联系的元信息（元信息以实体头域的形式表式）。

利用此204响应，客户端如果是一个用户代理，它就可以不用改变引起请求发送的文档视图（译注：如一篇html文档在浏览器里呈现的样子）。204状态响应主要的目的是允许输入，而不必引起用户代理当前文档视图的改变，虽然一些新的或更新了的元信息可能会应用于用户代理视图里的此文档。

204响应不能包含一个消息主体，并且在头域后包含一个空行结束。

205 重置内容（Reset Content）
205状态响应是服务器告诉用户代理应该重置引起请求被发送的文档视图。此响应主要的目的是清空文档视图表单里的输入框以便用户能输入其它信息。此响应不能包含一个实体。

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（部分的）响应。

重新定向 3xx.
这类状态码指明用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动执行而不需要用户的交互，并且进一步动作请求的方法必须为GET或HEAD。一个客户端应该发现无限的重定向回路，因为此回路能产生网络拥挤。

注意：以前此规范版本建议一个最多能有五个重定向。内容开发者应该知道客户端可能存在这个限制。

300 多个选择.（Multiple Choices）
资源对应有多个表现形式，客户端请求资源的表现形式对应于其中的一个，每个表现形式都有一个指向自己的位置(location)，并且代理驱动协商（agent-driven negotiation）能选择一个更适的表现形式并重定向请求到那个表现形式的位置。

除非是HEAD请求，否则300状态响应应该包含一个实体，此实体包含一个资源特性和位置列表，从这个列表里用户或用户代理能选择最合适的资源的表现形式。实体格式被Content-Type头域里的媒体类型指定。依赖于此格式和用户代理的能力，用户代理选择最合适的表现形式的行为可能会被自动执行。然而，此规范并没有定义自动执行行为的标准。

如果服务器能确定更好的表现形式，它应该为此表现形式在Location头域里包含一个特定的URI来指明此表现形式的位置；用户代理可能会利用此Location头域自动重定向。300状态响应是可缓存的除非被特别指明。

301 永久移动 （Moved Permanently）
请求资源被赋于一个新的永久的URI，并且任何将来对此资源的引用都会利用此301状态响应返回的URI。具有链接编辑能力的客户端应该能自动把请求URI的引用转到到服务器返回的新的引用下。此响应是能缓存的除非另外声明。

新的永久URI应该在响应中被Location头域给定。除非请求方法是HEAD，否则此响应的头域应该包含对此新URI超文本链接的一个超文本提示。

如果客户端接收了一个301状态响应，此响应相应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向请求，除非它能被用户确认，因为这可能会改变请求提交的条件。

注意：当客户端在接收了301状态码响应后，会重定向POST请求，一些已经存在的HTTP/1.0用户代理将错误的把此请求变成一个GET请求。

302 发现(Found)
请求的资源放在一个不同的暂时的URI下。因为重定向可能会偶尔被改变，客户端应该继续利用请求URI(Request-URI)为将来的请求。302响应是只有在Cache-Control或Expires头域指明的情况下才能被缓存。

临时的URI应该在Location头域里指定。除非请求方法是HEAD，否则响应的实体应该包含指向此新URI的超文本链接的短超超文本提示。

如果302状态代码在一个不是GET和HEAD方法请求的响应中，用户代理不能自动重定向请求除非用户确认可以自动重定向，因为这能改变请求提交的的条件。

注意：RFC1945和RFC2068指定客户端不能在重定向请求的时候改变请求方法。然而，大多数用户代理实现把302响应看成是303响应，根据Location头域值的URI执行GET请求，不管原始的请求方法。303和307状态响应的目的是为使服务器明白客户端期望哪种类型的重定向。

303 见其他(See Other)
请求的响应被放在一个不同的URI下，并且应该用GET方法获得那个资源。此方法的存在主要是允许POST执行脚本的输出重定向到用户选择的资源。新的URI并不是原始请求资源的代替引用。303响应不能被缓存，但是再次重定向请求的响应应该被缓存。

不同的URI应该在Location头域里指定。除非请求方法是HEAD，303响应的实体应该包含一个短的指向新的URI链接的超文本提示。

注意：许多HTTP/1.1以前版本的用户代理不能理解303状态响应。当这些客户端比较关注于互操作性的时候，302状态码应该被代替利用，因为大多用户代理对302响应的理解就是303响应。

304 没有被改变(Not Modified)
如果客户端已经执行了条件GET请求，并且访问服务器资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该以此状态码响应。304响应不能包含一个消息主体(message-body)，并且在头域后面总是以一个空行结束。

此响应必须包含下面的头域：

-Date，除非14.18.1指明的那些规则下Date是可以遗漏的。如果时钟不准确的源服务器遵循这些规则，并且代理服务器和客户端在接收了一个没有Date头域的响应后加上了自己的Date（这在RFC 2086里声明了，见14.19节），缓存将会正确地操作。

-ETag 和/或 Content-Location，如果这些头域已经在相请求的200响应里出现过。

Expires，Cache-Control，和/或 Vary，如果这些头域的域值可能与以前相同请求的响应的域值不一致。

如果条件GET用强缓存验证（见13.3.3）节，那么响应不应该包含其他的实体头域。当条件GET用于弱缓存验证时，那么响应不能包含其他的实体头域；这能防止缓存的实体主体和更新了的头域之间的不一致性。

如果304响应指明实体不能被缓存，那么此缓存必须遗弃此响应，并且以无条件请求重复请求。

如果缓存利用一个304响应去更新一个缓存项，那么此缓存必须更新缓存项里关于响应里新的域值的那些域值。

305 使用代理服务器 （User Proxy）
请求资源必须能通过代理服务器访问，代理服务器的地址在响应的Location头域里指定。Location头域指定了代理服务器的URI。接收者被期望通过代理服务器重复此请求，305响应必须能被源服务器产生。

注意：RFC 2068并没有说明305响应的目的是重定向一个独立请求，并且只能被源服务器产生。不注意这些限制会有重要的安全后果。

306没有使用的（unused）
306状态码被用于此规范以前的版本，是不再使用的意思，并且此状态码被保留。

307临时重发（Temporary Redirect）
请求的资源临时存在于一个不同的URI下。由于重新向可能会偶尔改变，所以客户端应该继续利用此请求URI（Request-URI）为将来的请求。307响应只有被Cache-Control或Expire头域指明时才能被缓存。

临时URI应该在响应的Location头域里给定。除非请求方法是HEAD，否则响应的实体应该包含一个指向新URI的超文本链接提示，因为许多HTTP/1.1以前的用户代理不能理解307状态响应。因此，此提示应该包含用户重复原始请求到新的URI的必需的信息。

如果307状态响应.对应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向此请求除非它能被用户确认它可以重定向，因为这可能改变请求提交的条件。

客户错误 4xx
状态码4xx类的目的是为了指明客户端出现错误的情况。除了当响应一个HEAD请求，服务器应该包含一个实体，此实体包含一个此错误请求的解释。此状态码对所有请求方法都是适合的。用户代理应该展示任何响应里包含的实体给用户。

如果客户端发送数据，利用TCP的服务器实现应该小心确保客户端回复包含在响应里的接收包，这在服务器关闭此输入连接前。如果在关闭连接后，客户端继续发送数据给服务器，那么服务器的TCP栈将发送一个重置包给客户端，

400 坏请求（Bad Request）
请求不能被服务器理解，由于错误的语法。客户端不应该没有改变请求而重复请求。

401 未授权的 （Unauthorized）
请求需要用户授权。响应必须包含一个WWW-Authenticate头域（见14.47），此头域包含一个适用于请求资源的授权的激发。客户端会以一个Authorization头域重复此请求。如果请求包含了一个授权证书，如果服务器以401响应，它指明这些证书的授权被拒绝。如果401响应包含一个同样的授权激发和以前的响应一样，并且用户代理已经尝试至少授权了一次，那么用户应该被呈现包含在响应里的实体，因为这些实体可能包含相关的诊断信息。HTTP授权访问在“HTTP Authentication：Basic and Digest Access Authentication”[43]里解释。

402 必需的支付 （Payment Required）
此状态码为将来的应用保留。

403 禁用 （Forbidden）
服务器理解此请求，但拒绝满足此请求。授权是没有作用的并且请求不能被重复。如果请求方法是HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么404状态码(Not Found)响应将被使用。

404 没有找到（Not Found）
服务器并没有找到任何可以匹配请求URI的资源。条件是长期的还是暂时的也没有被服务器指明。410（Gone）状态响应应该被使用，如果服务器知道一个旧的资源不能长期的使用并且没有转发地址时。 此状态码通常别用于当服务器不希望指出为什么请求被拒绝，或者没有任何其他响应是适合的。

405 不被允许的方法（Method Not Allowed）
此状态码表示请求行（Request-Line）里的方法对此资源来说不被允许。响应必须包含一个Allow头域，此头域包含以一系列对此请求资源有效的方法。

406 不接受的 （Not Acceptable）
根据客户端请求的接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, 或者 Accept-Language），服务器不能产生让客户端可以接受的响应。

除非是HEAD请求，响应应该包含一个实体，此实体包含一系列实体的特性和位置，通过他们用户或用户代理能选择最合适的资源的表现形式。实体格式被媒体类型指定。依赖于此格式和用户代理的能力，选择最合适的会被自动执行。然而，此规范并没有定义自动执行选择的标准。

注意：HTTP/1.1服务器被允许返回这样的响应，此响应根据接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, or Accept-Language）是不可接受的。在一些情况下，这可能更倾向于发送一个406响应。用户代理被鼓励观察响应来决定是否此响应是可接受的。

如果响应是不可接受的，用户代理应该暂时停止更多的数据的接收并且询问用户去决定进一步的动作。

407 代理服务器授权所需（Proxy Authentication Required）
此状态码和401（Unauthorized）相似，但是指明客户端必须首先利用代理服务器对自己授权。代理服务器必须返回一个Proxy-Authenticate头域（见14.33节），此头域包含一个适用于代理服务器的授权激发。客户端可能会重复此请求利用一个合适的Proxy-Autorization头域（见14.34节）。HTTP访问授权在“HTTP Authentication；Basic and Digest Access Authentication”[43]。

408 请求超时（Request Timeout）
客户端在服务器等待的时间里不能产生请求。客户端端可能在以后会重复此请求。

409 冲突 （Confilict）
请求不能完成由于和当前资源的状态冲突。此状态码只被允许出现在期望用户可能能解决此冲并且能重新提交此请求的情况下。响应主体应该包含足够的为用户认识此资源冲突的信息。理想的情况下，响应实体应该包含足够为用户或用户代理解决此问题的信息；然而，这是不可能的并且也是不需要的。

冲突最可能发生在响应PUT请求的时候。例如，如果版本被使用并且被提交的实体包含资源的改变，这些改变和以前的请求的改变想冲突，那么服务器应该使用409响应去指明它不能完成此请求。在这种情况下，此响应实体应该包含这两个版本的不同，响应的格式在响应的Content-Type头域里指定。

410 不存在（gone）
请求资源不再可以在服务器上得到并且也不知道转发地址（译注：转向此资源的地址）。此条件是长期条件。具有链接编辑能力的客户端应该在用户确认后删除请求URI的引用。如果服务器不知道或不能方便判定条件是否是长期的，那么此404（没有发现）状态响应将被代替利用。响应是可缓存的，除非另外申明。

410响应主要的目的是通知接收者资源不能被得到并且告诉接收者指向那个资源的连接已经被移动了。这样一个事件对时间要求比较严格的服务来说是比较普遍的，并且对属于个人但已经不在服务器站点工作的人的资源来说，这个事件来也是比较普遍的。把所有长期不能得到的资源标记成“gone”或保持这些标记任意长时间，这是没有必要的。

411 必需的长度 （Length Required）
此响应服务器拒绝接受没有包含Content-Length头域的请求。客户端可以重复此请求如果它添加了一个有效的Content-Length头域，此头域包含了请求消息里消息主体的长度。

412 先决条件失败 （Precondition Failed）
先决条件在一个或多个请求头域里指定，412响应是表明先决条件在服务器上测试等于false。此响应允许客户端把先决条件放到请求消息的元信息里（头域数据）。

413 请求实体太大
服务器拒绝处理请求因为请求实体太大以致达到服务器不愿意去处理。服务器可能关闭此连接去防止客户端继续请求。

如果条件是暂时的，服务器应该包含一个Retry-After头域用来指明此请求是暂时的并且什么时间后客户端应该重试。

414 请求URI太长（Request-URI Too Long）
服务器拒绝为请求服务因为此请求URI太长了以至于服务器不能理解。这种情况是很少的，只发生在当客户端把POST请求不合适地转换为带有大量查询信息的GET请求时。

415 不被支持的媒体类型（Unsupported Media Type）
服务器拒绝为请求服务因为请求的实体的格式不能被请求的资源支持。

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媒体类型。

417 期望失败
Expect请求头域里指定的希望不能被服务器满足，或者，如果服务器是代理服务器，服务器有有不确定的理由确定请求不能被下一站的服务器满足。

服务器错误 5xx （Server Error）
这类状态码指明服务器处理请求时产生错误或不能处理请求。除了HEAD请求，服务器应该包含一个实体，此实体用来解释错误，和是否是暂时或长期条件。用户代理应该展示实体给用户。此响应状态码能应用于任何请求方法。

500 服务器内部错误 （Internal Server Error）
服务器遇到了一个意外条件，此条件防止服务器满足此请求。

10.5.2 501 不能实现 （Not Implemented）
服务器不能支持满足请求的功能需求。这个响应是很合适的当服务器不能识别请求方法时并且不能支持它请求的资源的时候。

502 坏网关 （Bad Gateway）
此响应说明：服务器，当作为网关或代理时，它从上行服务器接收了一个无效的响应并尝试满足客户端的请求。

503 难以获得的服务.（Service Unavailable）
服务器不能处理请求由于服务器暂时的过载或维护。这就是说这是暂时条件，此条件将会在一些延时后被减轻。延迟的长度可以在Retry-After头域里指定。如果没有Retry-After被给，那么客户端应该处理此响应就像它处理500响应一样。

注意：503状态码的存在并不是意指服务器当产生过载时必须利用它。一些服务器可能希望拒绝此连接。

504 网关超时（Gateway Timeout）
服务器，当作为网关或代理服务器时，不能接收一个从被URI指定的上行服务器的响应（例如：HTTP，FTP，LDAP服务器）或者它为完成请求而需要访问的一些其他的辅助性服务器（例如：DNS服务器）。

注意：一些部署的代理服务器将会返回400或500响应当DNS查找超时。

505  HTTP版本不支持 （HTTP version Not Supported）
服务器不能支持，或拒绝支持，此HTTP协议版本消息。505响应指明服务器不能或不愿意完成这样的请求，这在3.1中描述了。此响应应该包含一个实体，此实体描述了为什么此协议版本不被支持和其他的能被服务器支持的协议版本。