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