状态码定义
part of Hypertext Transfer Protocol -- HTTP/1.1
RFC 2616 Fielding, et al.
10状态码定义
每个状态代码的描述如下，包括对它可以遵循的方法的描述以及响应中所需的任何元信息。
10.1信息性1xx
此类状态代码表示仅由状态行和可选标头组成的临时响应，并以空行终止。此类状态码没有必需的标题。由于HTTP / 1.0没有定义任何1xx状态代码，因此服务器必须禁止在实验条件下向HTTP / 1.0客户端发送1xx响应。
即使客户端不希望收到100（继续）状态消息，客户端也必须准备在常规响应之前接受一个或多个1xx状态响应。用户代理可能会忽略意外的1xx状态响应。
代理必须转发1xx响应，除非代理与其客户端之间的连接已关闭，或者代理本身请求生成1xx响应。（例如，如果
代理在转发请求时会添加“期望：100-继续”字段，则无需转发相应的100（继续）响应。）
10.1.1 100继续
客户应继续其请求。此临时响应用于通知客户端请求的初始部分已被接收并且尚未被服务器拒绝。客户端应该继续发送剩余的请求，或者，如果请求已经完成，则忽略该响应。请求完成后，服务器必须发送最终响应。有关此状态码的使用和处理的详细讨论，请参见8.2.3节。
10.1.2 101交换协议
服务器理解并愿意通过“升级消息头”字段（第14.42节）来满足客户端对在此连接上使用的应用协议进行更改的请求。服务器将在终止101响应的空行之后立即将协议切换到由响应的Upgrade标头字段定义的协议。
仅在有利时才应切换协议。例如，切换到新版本的HTTP优于旧版本，并且在传递使用此类功能的资源时，切换到实时同步协议可能是有利的。
10.2成功的2xx
此类状态码表示已成功接收，理解并接受了客户的请求。
10.2.1 200确定
该请求已成功。响应返回的信息取决于请求中使用的方法，例如：
在响应中发送与请求的资源相对应的实体；
HEAD对应于所请求资源的实体头字段在响应中发送，没有任何消息主体；
POST描述或包含操作结果的实体；
跟踪包含最终服务器接收到的请求消息的实体。
10.2.2 201已创建
该请求已完成，并导致创建了新资源。可以通过响应实体中返回的URI引用新创建的资源，其中最具体的URI由Location头字段给出。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由Content-Type标头字段中提供的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果不能立即执行该操作，则服务器应以202（已接受）响应代替。
201响应可能包含ETag响应标头字段，该字段指示刚刚创建的所请求的变体的实体标签的当前值，请参见14.19节。
10.2.3 202接受
该请求已被接受进行处理，但是处理尚未完成。该请求最终可能会执行，也可能不会最终执行，因为在实际进行处理时可能会不允许该请求。无法通过这样的异步操作重新发送状态代码。
202响应是有意拒绝的。其目的是允许服务器接受某个其他进程的请求（也许是每天仅运行一次的面向批处理的进程），而无需用户代理与服务器的连接一直持续到该进程完成为止。随此响应返回的实体应包括请求当前状态的指示，以及指向状态监视器的指针或用户何时可以期望完成请求的一些估计。
10.2.4 203非权威信息
实体标头中返回的元信息不是原始服务器可用的权威集，而是从本地或第三方副本收集的。呈现的集合可以是原始版本的子集或超集。例如，包括有关资源的本地注释信息可能会导致原始服务器已知的元信息的超集。不需要使用此响应代码，仅当响应为200（确定）时才适用。
10.2.5 204无内容
服务器已满足请求，但不需要返回实体，可能要返回更新的元信息。响应可以以实体标题的形式包括新的或更新的元信息，如果存在，则应与所请求的变体相关联。
如果客户端是用户代理，则不应更改导致发送请求的文档视图。尽管任何新的或更新的元信息都应应用于当前在用户代理的活动视图中的文档，但该响应主要旨在允许输入操作而不会导致更改用户代理的活动文档视图。
204响应必须不包含消息正文，因此始终由标头字段之后的第一个空行终止。
10.2.6 205重置内容
服务器已经完成了请求，并且用户代理应该重置导致请求发送的文档视图。该响应主要旨在允许通过用户输入进行操作的输入，然后清除给出输入的形式，以便用户可以轻松地发起另一个输入操作。响应中不得包含实体。
10.2.7 206部分内容
服务器已完成对资源的部分GET请求。请求必须包含一个指示期望范围的Range头域（第14.35节），并且可能包含一个If-Range头域（第14.27节）以使请求成为条件请求。
响应必须包括以下头域：
-Content-Range标头字段（第14.16节）指示
此响应包含的范围，或多部分/字节范围
Content-Type，包括每个部分的Content-Range字段。如果一个
响应中存在Content-Length标头字段，
值必须与在
邮件正文。
-日期
-ETag和/或Content-Location（如果标头已发送）
在对同一请求的200条回复中
-如果字段值可能会过期，缓存控制和/或变化
与先前的任何回复中发送的相同
变体
如果206响应是使用强缓存验证器的If-Range请求的结果（请参阅第13.3.3节），则响应不应包含其他实体标头。如果响应是使用弱验证器的If-Range请求的结果，则该响应务必不包括其他实体标头；这样可以避免缓存的实体与更新的标头之间的不一致。否则，响应必须包括所有对同一请求返回200（确定）响应的实体头。
如果ETag或Last-Modified头不完全匹配，则缓存不得将206响应与其他先前缓存的内容组合在一起，请参见13.5.4。
不支持Range和Content-Range头的缓存必须不缓存206（部分）响应。
10.3重定向3xx
此类状态码表示用户代理需要采取进一步的措施才能满足请求。当且仅当第二个请求中使用的方法是GET或HEAD时，才可以由用户代理执行所需的操作，而无需与用户进行交互。客户端应该检测到无限重定向循环，因为这样的循环会为每个重定向生成网络流量。
注意：本规范的先前版本建议使用
最多五个重定向。内容开发人员应注意
可能会有客户实施了这样的固定
局限性。
10.3.1 300个多项选择
所请求的资源与一组表示中的任何一个相对应，每个都有自己的特定位置，并且提供了代理驱动的协商信息（第12节），以便用户（或用户代理）可以选择首选的表示并重定向其请求到该位置。
除非它是HEAD请求，否则响应应包含一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由“内容类型”标头字段中提供的媒体类型指定。取决于格式和功能
用户代理，可以自动执行最合适的选择。但是，该规范没有为这种自动选择定义任何标准。
如果服务器具有首选的表示形式，则应在“位置”字段中包含该表示形式的特定URI；用户代理可以使用“位置”字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。
10.3.2 301永久移动
所请求的资源已被分配了一个新的永久URI，以后对该资源的任何引用都应使用返回的URI之一。具有链接编辑功能的客户端应在可能的情况下自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。
新的永久URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含简短的超文本注释，并带有指向新URI的超链接。
如果接收到响应GET或HEAD以外的请求的301状态代码，则用户代理不得自动重定向该请求，除非用户可以确认，因为这可能会更改发出该请求的条件。
注意：在之后自动重定向POST请求时
收到301状态代码，一些现有的HTTP / 1.0用户代理
会错误地将其更改为GET请求。
10.3.3找到302
所请求的资源临时位于其他URI下。由于重定向有时可能会更改，因此客户端应继续将Request-URI用于将来的请求。仅当由Cache-Control或Expires标头字段指示时，此响应才可缓存。
临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含简短的超文本注释，并带有指向新URI的超链接。
如果响应GET或HEAD以外的请求而收到302状态码，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件。
注意：RFC 1945和RFC 2068指定不允许客户端
更改重定向请求的方法。但是，大多数
现有的用户代理实现将302视为303
响应，无论位置字段值如何执行GET
原始请求方法。状态码303和307具有
为希望明确指出哪个服务器添加了
期望客户有种反应。
10.3.4 303查看其他
可以在不同的URI下找到对请求的响应，并且应该使用该资源上的GET方法来检索该请求。存在此方法主要是为了允许POST激活脚本的输出将用户代理重定向到所选资源。新URI不能替代原始请求的资源。303响应一定不能被缓存，但是对第二个（重定向的）请求的响应可能是可缓存的。
响应中的Location字段应提供不同的URI。除非请求方法是HEAD，否则响应的实体应该包含简短的超文本注释，并带有指向新URI的超链接。
注意：许多HTTP / 1.1之前的用户代理不了解303
状态。当需要考虑与此类客户端的互操作性时，
因为大多数用户代理都会做出反应，所以可以改用302状态代码
302响应，如此处针对303所述。
10.3.5 304未修改
如果客户端已经执行了有条件的GET请求，并且允许访问，但是文档没有被修改，则服务器应该以该状态码响应。304响应必须不包含消息正文，因此始终由标头字段之后的第一个空行终止。
响应必须包括以下头域：
-日期，除非第14.18.1节要求省略
如果无时钟源服务器遵守这些规则，并且代理和客户端将自己的日期添加到没有响应的任何响应中（如[RFC 2068]第14.19节所指定的），缓存将正常运行。
-ETag和/或Content-Location（如果标头已发送）
在对同一请求的200条回复中
-如果字段值可能会过期，缓存控制和/或变化
与先前的任何回复中发送的相同
变体
如果条件GET使用了强缓存验证器（请参阅第13.3.3节），则响应不应包含其他实体头。否则（即，条件GET使用弱验证器），响应必须不包括其他实体头；这样可以避免缓存的实体与更新的标头之间的不一致。
如果304响应指示当前未缓存的实体，则缓存必须忽略该响应，并在没有条件的情况下重复该请求。
如果缓存使用收到的304响应来更新缓存条目，则缓存必须更新该条目以反映响应中给定的任何新字段值。
10.3.6 305使用代理
所请求的资源必须通过位置字段给出的代理访问。位置字段提供代理的URI。预计收件人将通过代理重复此单个请求。305个响应只能由原始服务器生成。
注意：RFC 2068尚不清楚305是否旨在重定向
单个请求，并且仅由原始服务器生成。不
遵守这些限制会带来重大的安全后果。
10.3.7 306（未使用）
306状态代码在规范的先前版本中使用，不再使用，并且保留该代码。
10.3.8 307临时重定向
所请求的资源临时位于其他URI下。由于重定向有时可能会改变，因此客户端应该继续使用Request-URI进行以后的请求。仅当由Cache-Control或Expires标头字段指示时，此响应才可缓存。
临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应包含简短的超文本注释，并带有指向新URI的超链接，因为许多HTTP / 1.1之前的用户代理不了解307状态。因此，注释应该包含用户在新URI上重复原始请求所必需的信息。
如果响应GET或HEAD以外的请求而收到307状态码，则用户代理不得自动重定向该请求，除非用户可以确认，因为这可能会更改发出该请求的条件。
10.4客户端错误4xx
状态码4xx类用于客户端似乎已出错的情况。除响应HEAD请求外，服务器应包含一个实体，该实体包含错误情况的说明，以及它是暂时还是永久的情况。这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。
如果客户端正在发送数据，则使用TCP的服务器实现应小心确保在服务器关闭输入连接之前，客户端确认收到包含响应的数据包。如果关闭后客户端继续向服务器发送数据，则服务器的TCP堆栈将向客户端发送重置数据包，这可能会擦除客户端未确认的输入缓冲区，然后HTTP应用程序才能读取和解释它们。
10.4.1 400错误的请求
由于语法格式错误，服务器无法理解该请求。客户不应在没有修改的情况下重复请求。
10.4.2 401未经授权
该请求需要用户认证。响应必须包括一个WWW-Authenticate头域（第14.47节），其中包含适用于所请求资源的质询。客户端可以使用适当的Authorization标头字段重复请求（第14.8节））。如果请求已包含授权凭证，则401响应指示已拒绝这些凭证的授权。如果401响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，则应向用户提供响应中给定的实体，因为该实体可能包括相关的诊断信息。HTTP访问身份验证在“ HTTP身份验证：基本和摘要访问身份验证” [43]中进行了说明。
10.4.3 402需要付款
该代码保留供将来使用。
10.4.4 403禁止
服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）来代替。
10.4.5找不到404
服务器未找到与请求URI匹配的任何内容。没有迹象表明这种情况是暂时的还是永久的。如果服务器通过某种内部可配置的机制得知旧资源永久不可用并且没有转发地址，则应使用410（已消失）状态代码。当服务器不希望确切显示请求被拒绝的原因或没有其他响应可应用时，通常使用此状态代码。
10.4.6 405方法不允许
Request-URI标识的资源不允许使用Request-Line中指定的方法。响应必须包含一个Allow标头，其中包含所请求资源的有效方法列表。
10.4.7 406不可接受
由请求标识的资源仅能够生成响应实体，该响应实体具有根据请求中发送的接受标头不可接受的内容特征。
除非它是HEAD请求，否则响应应包括一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个。实体格式由Content-Type标头字段中提供的媒体类型指定。根据用户代理的格式和功能，可以自动执行最合适的选择。但是，该规范没有为这种自动选择定义任何标准。
注意：允许HTTP / 1.1服务器返回以下响应：
根据在
请求。在某些情况下，这甚至可能比发送
406回应。鼓励用户代理检查的标题
确定是否可接受的传入响应。
如果响应是不可接受的，则用户代理应暂时停止接收更多数据，并向用户查询有关进一步操作的决定。
10.4.8需要 407代理身份验证
此代码类似于401（未授权），但表示客户端必须首先使用代理对其进行身份验证。代理务必返回一个Proxy-Authenticate头域（第14.33节），其中包含适用于所请求资源的代理的质询。客户可以用合适的代理授权头域（第14.34节）重复请求。HTTP访问身份验证在“ HTTP身份验证：基本和摘要访问身份验证” [43]中进行了说明。
10.4.9 408请求超时
在服务器准备等待的时间内，客户端未发出请求。客户端可以在以后的任何时候重复请求而不做任何修改。
10.4.10 409冲突
由于与资源的当前状态存在冲突，因此无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应包含足够的内容
供用户识别冲突源的信息。理想情况下，响应实体应包括足够的信息以供用户或用户代理解决问题。但是，这可能是不可能的，也不是必需的。
响应PUT请求最有可能发生冲突。例如，如果正在使用版本控制，并且正在PUT的实体包括对资源的更改，该更改与先前（第三方）请求所做的更改冲突，则服务器可能会使用409响应来指示它无法完成该请求。在这种情况下，响应实体可能会以响应Content-Type定义的格式包含两个版本之间差异的列表。
10.4.11 410去了
请求的资源在服务器上不再可用，并且未知转发地址。可以认为这种情况是永久的。具有链接编辑功能的客户端应在用户批准后删除对Request-URI的引用。如果服务器不知道该条件是否永久存在，或者无法确定该条件是否永久存在，则应改用状态代码404（未找到）。除非另有说明，否则此响应是可缓存的。
410响应主要用于通过通知接收者资源有意不可用以及服务器所有者希望删除指向该资源的远程链接来辅助Web维护任务。对于限时促销服务和属于不再在服务器站点工作的个人的资源而言，此类事件很常见。不必将所有永久不可用的资源标记为“已消失”，也不必将标记保留任何时间长度-服务器所有者可以自行决定。
10.4.12 411长度要求
服务器拒绝在没有定义Content-Length的情况下接受请求。如果客户端在请求消息中添加了一个有效的Content-Length头字段，其中包含消息主体的长度，则客户端可以重复该请求。
10.4.13 412前提条件失败
在服务器上进行测试时，在一个或多个请求标头字段中给出的前提条件被评估为false。此响应代码允许客户端在当前资源元信息（标头字段数据）上放置先决条件，从而防止所请求的方法应用于除预期资源之外的其他资源。
10.4.14 413请求实体太大
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的实体。服务器可以关闭连接，以防止客户端继续请求。
如果条件是临时的，则服务器应包括Retry- After标头字段以指示它是临时的，并且客户端可以在什么时间之后重试。
10.4.15 414请求URI太长
服务器拒绝处理请求，因为Request-URI的长度比服务器愿意解释的时间长。仅当客户端将POST请求转换为带有长查询信息的GET请求时，当客户端下降到重定向的URI“黑洞”（例如，指向URI的重定向URI前缀）时，才会发生这种罕见情况后缀），或者当服务器受到客户端的攻击时，该客户端试图使用固定长度的缓冲区来读取或处理Request-URI来利用某些服务器中存在的安全漏洞。
10.4.16 415不支持的媒体类型
服务器拒绝为请求提供服务，因为请求的实体的格式不受请求的方法所请求的资源支持。
10.4.17 416请求的范围不满足
如果请求包含Range请求标头字段（第14.35节），并且该字段中的range-specifier值均不与所选资源的当前范围重叠，则服务器应返回带有此状态代码的响应。包含If-Range请求标头字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置大于所选资源的当前长度。）
当针对字节范围请求返回此状态代码时，响应应包含一个Content-Range实体头字段，该字段指定所选资源的当前长度（请参见14.16节 ）。此响应绝对不能使用multipart / byteranges内容类型。
10.4.18 417预期失败
此服务器无法满足在Expect请求标头字段（请参阅第14.20节）中给出的期望，或者，如果该服务器是代理，则该服务器有明确的证据表明下一跳服务器无法满足该请求。
10.5服务器错误5xx
以数字“ 5”开头的响应状态代码表示服务器知道服务器已出错或无法执行请求的情况。除响应HEAD请求外，服务器应包含一个实体，该实体包含错误情况的说明，以及它是暂时还是永久的情况。用户代理应该向用户显示任何包含的实体。这些响应代码适用于任何请求方法。
10.5.1 500内部服务器错误
服务器遇到意外情况，阻止其满足请求。
10.5.2 501未实现
服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且不支持任何资源时，这是适当的响应。
10.5.3 502错误的网关
该服务器在充当网关或代理的同时，从尝试访问该请求的上游服务器接收到无效响应。
10.5.4 503服务不可用
由于暂时的服务器过载或维护，服务器当前无法处理该请求。这意味着这是一个暂时性状况，经过一段时间的延迟后会缓解。如果知道的话，延迟的长度可以在Retry-After头中指出。如果没有给出Retry-After，则客户端应该像处理500响应那样处理响应。
注意：503状态代码的存在并不意味着
服务器在过载时必须使用它。一些服务器可能希望
简单地拒绝连接。
10.5.5 504网关超时
该服务器虽然充当网关或代理，但未及时收到由URI指定的上游服务器（例如HTTP，FTP，LDAP）或尝试完成访问所需访问的某些其他辅助服务器的响应（例如DNS）请求。
注意：实施者注意：已知一些已部署的代理
DNS查找超时时返回400或500。
10.5.6 505 HTTP版本不受支持
服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。如第3.1节所述，服务器会使用该客户端的主版本指示它无法或不愿意完成该请求 ，但该错误消息除外。响应应该包含一个实体，描述为什么不支持该版本以及该服务器支持哪些其他协议。
