RFC 2616 Fielding，et al。
10状态码定义
下面描述每个状态代码，包括它可以遵循的方法的描述以及响应中所需的任何元信息。
10.1信息1xx
这类状态码表示临时响应，仅包含状态行和可选标题，并由空行结束。这类状态码没有必要的标题。由于HTTP / 1.0没有定义任何1xx状态码，除了实验条件外，服务器不能向HTTP / 1.0客户端发送1xx响应。
客户端必须准备好在定期响应之前接受一个或多个1xx状态响应，即使客户端不期望100（继续）状态消息。意外的1xx状态响应可能会被用户代理忽略。
代理必须转发1xx响应，除非代理与其客户端之间的连接已关闭，或除非代理本身请求生成1xx响应。（例如，如果a
代理在转发请求时添加了“Expect：100-continue”字段，则无需转发相应的100（继续）响应。）
10.1.1 100继续
客户端应该继续其请求。此临时响应用于通知客户端请求的初始部分已收到并且尚未被服务器拒绝。客户端应该继续发送请求的其余部分，或者如果请求已经完成，则忽略此响应。请求完成后，服务器必须发送最终响应。有关使用和处理此状态码的详细讨论，请参见第8.2.3节。
10.1.2 101切换协议
服务器通过升级消息头字段（14.42节）了解并愿意遵守客户端的请求，以改变此连接上使用的应用协议。服务器会将协议切换到响应的“升级”标题字段所定义的协议，紧接在终止101响应的空行之后。
协议只有在有利的情况下才能切换。例如，切换到更新版本的HTTP比旧版本更有优势，并且在交付使用这些功能的资源时切换到实时同步协议可能会有所帮助。
10.2成功2xx
这类状态码表明客户的请求已被成功接收，理解和接受。
10.2.1 200 OK
该请求已成功。与响应一起返回的信息取决于请求中使用的方法，例如：
在响应中发送GET请求资源对应的实体;
HEAD在响应中发送与所请求的资源相对应的实体标题字段，而没有任何消息体;
发布描述或包含行动结果的实体;
跟踪由最终服务器收到的包含请求消息的实体。
10.2.2 201创建
请求已经完成并且导致创建新的资源。新创建的资源可以由响应实体中返回的URI（s）引用，其中由Location标题字段给出的资源的URI最具体。响应应该包括一个实体，其中包含资源特性和位置的列表，用户或用户代理可以从中选择最合适的资源。实体格式由Content-Type头字段中给出的媒体类型指定。源服务器必须在返回201状态码之前创建资源。如果这个动作不能立即执行，服务器应该用202（Accepted）响应来响应。
一个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-Range字段。如果一个 内容长度标题字段存在于响应中 值必须与实际发送的OCTET数相匹配 邮件正文。
- 日期
- ETag和/或Content-Location，如果头部已被发送 在对同一请求的200响应中
- 如果字段值可能会过期，缓存控制和/或变化 不同于以前任何回复中发送的相同内容 变种
如果206响应是使用强大缓存验证器的If-Range请求的结果（请参阅第13.3.3节），那么响应不应包含其他实体头。如果响应是使用弱验证器的If范围请求的结果，那么响应绝不能包含其他实体头; 这可以防止缓存的实体和更新的标题之间的不一致。否则，响应必须包含所有将返回200（OK）响应给相同请求的实体头。
如果ETag或Last-Modified标头不完全匹配，则缓存不得将206响应与其他先前缓存的内容组合起来，请参见13.5.4。
不支持Range和Content-Range标头的缓存不得缓存206（部分）响应。
10.3重定向3xx
这类状态码表明用户代理需要采取进一步行动来完成请求。当且仅当第二个请求中使用的方法是GET或HEAD时，所需的操作可以由用户代理执行，而不与用户交互。客户端应该检测到无限重定向循环，因为这样的循环会为每个重定向生成网络流量。
注意：此规范的以前版本推荐使用a 最多五个重定向。内容开发人员应该意识到 有可能有客户实施这样的固定 局限性。
10.3.1 300多种选择
所请求的资源对应于一组表示中的任何一个，每个表示具有其自己的特定位置，并且正在提供代理驱动的协商信息（第12节），以便用户（或用户代理）可以选择优先表示并将其重定向请求到该位置。
除非是HEAD请求，否则响应应该包含一个实体，该实体包含资源特征和位置列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头部字段中给出的媒体类型指定。取决于格式和功能
用户代理，选择最合适的选择可以自动执行。但是，本规范没有为这种自动选择定义任何标准。
如果服务器有一个首选的表示形式，它应该在位置字段中包含该表示的特定URI; 用户代理可以使用位置字段值进行自动重定向。除非另有说明，否则此响应可缓存。
10.3.2 301永久移动
被请求的资源已经被分配了一个新的永久URI，并且任何将来对这个资源的引用都应该使用返回的URI之一。在可能的情况下，具有链接编辑功能的客户端应自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应可缓存。
新的永久URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本注释。
如果接收到301状态代码以响应除GET或HEAD以外的请求，则用户代理绝不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。
注意：之后自动重定向POST请求时 接收301状态码，一些现有的HTTP / 1.0用户代理 将错误地将其更改为GET请求。
10.3.3 302找到
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会发生变化，因此客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires标头字段指示，此响应仅可缓存。
临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本注释。
如果接收到302状态码以回应除GET或HEAD以外的请求，则用户代理绝不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。
注意：RFC 1945和RFC 2068指定客户端不被允许 在重定向的请求上更改方法。但是，大部分 现有的用户代理实现将302看作是303 响应，无论如何在位置字段值上执行GET 的原始请求方法。状态码303和307有 已被添加到希望明确清楚哪个服务器 预计客户会有种类的反应。
10.3.4 303见其他
对请求的响应可以在不同的URI下找到，并且应该在该资源上使用GET方法检索。此方法主要用于允许POST激活的脚本的输出将用户代理重定向到选定的资源。新的URI不是最初请求的资源的替代参考。303响应绝不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。
不同的URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本注释。
注意：许多pre-HTTP / 1.1用户代理不理解303 状态。当与这些客户的互操作性是一个问题时， 可以使用302状态码，因为大多数用户代理都会作出反应 到303这里所描述的302响应。
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使用代理
必须通过Location字段给出的代理访问请求的资源。位置字段给出代理的URI。预计收件人将通过代理重复此单个请求。305响应只能由原始服务器生成。
注意：RFC 2068不清楚305是否打算重定向一个 单个请求，并且仅由原始服务器生成。不 观察这些限制会带来重大的安全后果。
10.3.7 306（未使用）
306状态码用于规范的先前版本，不再使用，代码保留。
10.3.8 307临时重定向
请求的资源暂时驻留在不同的URI下。由于有时可能会改变重定向，所以客户端应该继续使用请求URI来做未来的请求。如果由Cache-Control或Expires标头字段指示，此响应仅可缓存。
临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应实体应该包含一个超链接到新URI的简短超文本注释，因为许多pre-HTTP / 1.1用户代理不理解307状态。因此，注释应该包含用户在新URI上重复原始请求所需的信息。
如果接收到307状态码以回应GET或HEAD以外的请求，则用户代理绝不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。
10.4客户端错误4xx
4xx类状态码适用于客户端出现错误的情况。除了响应HEAD请求之外，服务器应该包含一个包含错误情况解释的实体，以及它是临时还是永久性条件。这些状态码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。
如果客户端正在发送数据，则使用TCP的服务器实现应该小心，以确保客户端在服务器关闭输入连接之前确认收到了包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，则服务器的TCP堆栈将向客户端发送重置数据包，这可能会在HTTP应用程序可以读取和解释客户端的未确认输入缓冲区之前擦除它们。
10.4.1 400错误请求
由于格式错误，服务器无法理解请求。客户端不应该在没有修改的情况下重复请求。
10.4.2 401未经授权
该请求需要用户认证。响应必须包含一个WWW-Authenticate头域（14.47节），其中包含一个适用于所请求资源的挑战。客户端可以用合适的授权标题字段重复请求（14.8节））。如果请求已包含授权凭证，则401响应表明授权已被拒绝。如果401响应包含与先前响应相同的挑战，并且用户代理至少已经尝试了一次认证，则用户应该被呈现给响应中的实体，因为该实体可能包含相关的诊断信息。HTTP访问认证在“HTTP认证：基本和摘要访问认证” [43]中解释。
10.4.3需要付款402
此代码保留供将来使用。
10.4.4 403禁止
服务器了解请求，但拒绝履行它。授权不起作用，请求不应重复。如果请求方法不是HEAD并且服务器希望公开为什么请求没有被满足，那么它应该描述在实体中拒绝的原因。如果服务器不希望将该信息提供给客户端，则可以使用状态码404（未找到）代替。
10.4.5 404未找到
服务器没有找到与Request-URI匹配的任何内容。没有迹象表明病情是暂时的还是永久性的。如果服务器通过某种内部可配置机制知道旧资源永久不可用且没有转发地址，则应使用410（Gone）状态码。当服务器不希望揭示请求被拒绝的原因时，或者没有其他响应适用时，通常使用此状态码。
10.4.6 405方法不允许
Request-URI中指定的方法不允许使用Request-URI标识的资源。响应必须包含一个Allow头，其中包含请求资源的有效方法列表。
10.4.7 406不可接受
根据请求中发送的接受头，由请求标识的资源仅能够生成具有不可接受的内容特征的响应实体。
除非是HEAD请求，否则响应应该包含一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的实体特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。根据用户代理的格式和功能，可以自动选择最合适的选项。但是，本规范没有为这种自动选择定义任何标准。
注意：HTTP / 1.1服务器被允许返回响应 根据发送的接受标题不可接受 请求。在某些情况下，这可能比发送一个 406响应。鼓励用户代理检查标题 一个即将到来的回应来确定它是否可以接受。
如果响应不可接受，用户代理应该暂时停止接收更多数据，并询问用户是否有进一步的行动。
10.4.8 407需要代理验证
此代码与401（未授权）类似，但表示客户端必须首先使用代理进行身份验证。代理必须返回一个代理 - 认证标头字段（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（Not Found）（代替）。除非另有说明，否则此响应可缓存。
410响应主要用于通过通知接收方资源有意无法使用以及服务器所有者希望移除到该资源的远程链接来帮助进行网络维护。这样的事件对于时间有限的促销服务以及属于不再在服务器现场工作的个人的资源是很常见的。没有必要将所有永久不可用资源标记为“不存在”或将标记保留任意时间长度 - 这由服务器所有者决定。
10.4.12 411所需长度
没有定义的内容长度，服务器拒绝接受请求。如果请求消息中添加了包含消息体长度的有效Content-Length头域，客户端可以重复请求。
10.4.13 412 先决条件失败
在服务器上测试时，在一个或多个请求头字段中给出的前提条件评估为false。此响应代码允许客户端将当前资源元信息（头字段数据）的先决条件放置，从而防止将所请求的方法应用于除预期的资源之外的资源。
10.4.14 413请求实体太大
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的大小。服务器可以关闭连接以防止客户端继续请求。
如果条件是临时的，服务器应该包含一个Retry-After头域来表明它是临时的，并且在什么时候客户端可以再次尝试。
10.4.15 414请求URI太长
服务器拒绝为请求提供服务，因为Request-URI比服务器愿意解释的时间长。这种罕见情况只有在客户端将POST请求不正确地转换为具有长查询信息的GET请求时才会发生，当客户端已经下降到重定向的URI“黑洞”时（例如，指向的重定向URI前缀它本身的后缀），或者当服务器受到试图利用固定长度缓冲区中存在的安全漏洞来读取或操作Request-URI的客户端的攻击时。
10.4.16 415不支持的媒体类型
服务器拒绝为请求提供服务，因为请求的实体的格式不是所请求方法的请求资源支持的格式。
10.4.17 416请求范围不满足
如果一个请求包含一个Range request-header字段（14.35节），并且这个字段中的范围说明符值都不与选定资源的当前范围重叠，那么服务器应该返回带有这个状态码的响应，并且请求没有包含一个If-Range请求标题字段。（对于字节范围，这意味着所有byte-range-spec值的first-byte-pos都大于所选资源的当前长度。）
当这个状态码返回一个字节范围请求时，响应应该包含一个Content-Range实体标题字段，用于指定所选资源的当前长度（见14.16节 ）。该响应不得使用多部分/字节范围的内容类型。
10.4.18 417期望失败
预期的请求头字段（请参阅第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状态码的存在并不意味着a 服务器在重载时必须使用它。有些服务器可能希望 简单地拒绝连接。
10.5.5 504网关超时
当作为网关或代理服务器时，服务器没有收到由URI指定的上游服务器（例如HTTP，FTP，LDAP）或其他辅助服务器（例如DNS）的及时响应，这些服务器在尝试完成时需要访问请求。
注意：对实现者的注意事项：一些已部署的代理已知 当DNS查找超时时返回400或500。
10.5.6不支持505 HTTP版本
服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。服务器指示它不能或不愿意使用与客户端相同的主要版本来完成请求，如第3.1节所述 ，而不是使用此错误消息。响应应该包含一个实体，描述不支持该版本的原因以及该服务器支持的其他协议。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
