持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第15天，点击查看活动详情
- 状态码依赖于请求方法的描述和向应力需要的任何元信息的描述。
代表通知1xx
- 这类状态码代表了一个临时的响应，没有必须的头部。
- 客户端必须能在一个常规响应之前接受一个或多个1xx状态，即使客户端不期望100状态响应，不被客户端期望的1xx可能会被用户代理忽略。
- 代理必须能转发1xx响应，除非代理和它的客户端的链接关闭了，或者代理自己响应请求并产生1xx响应。
100（继续）
- 100状态响应告诉客户端应该继续请求。100响应是个中间响应，被用于通知客户端请求的初始部门已经被接受了，服务器没有丢弃这个请求。客户端应该继续发送请求的剩余部分。
101（切换协议）
- 服务器理解并且愿意遵循刻画段的请求，请求会通过Upgrade头部指明一个应用层协议改变协议。服务器会响应这个请求然后按照Upgrade里指明的协议，会以一个空行结束这个101响应。
- 当协议切换可以受益时，应该考虑切换。
代表成功的2xx
- 这类状态码表示客户端的请求已经被服务器成功的接收、理解并且接受了。
200（OK）
- 此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法。
201（已创建）
- 请求被服务器接收并且产生了一个新的资源。新创建的资源URI在响应实体里返回，但是此资源最精确的URI是在Location头部里给出的。
- 实体格式被Content-type头部的媒体类型指定。服务器必须能在返回201状态码之前建立资源。如果不能立即创建资源（比如post方法），那么服务器应该以202响应代替。
- 一个201响应可以包含一个ETag响应，这个值表示当前请求变量也就是刚刚创建的资源的实体标签值。
202（接受）
- 请求已经被接受去处理，但是还没有处理完成。请求可能处理不完，因为有处理过程中拒绝处理的可能。
- 202响应是非担保性的。为了允许服务器可以处理接收请求而不需要用户代理在处理没有完成之前长期连接到服务器。 （比如每天执行一次的批处理）。响应里的实体应该包含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估值。
203（非权威信息）
- 表示响应里实体头部元信息不能从源服务器获得，而是从本地或第三方响应的副本里收集的。
- 这个状态响应码不是必须使用，但是比200（OK）响应功更合适。
204（无内容）
- 服务器已经满足了请求但并美欧返回一个实体，而是返回更新的元信息。此响应可能包含新的活更新的元信息，这些元信息应该和请求变量相关。
- 利用204响应，当客户端是一个用户代理，客户端可以不用改变请求发送的文档视图（比如浏览器展示html文档）。
- 204状态响应主要的目的是允许输入，而不用引起用户代理当前展示的文档试图的改变，但是新的或更新的元信息会应用于用户代理视图里当前的文档。
- 204响应不能包含消息主体，并且在头部后包含一个空行结束。
205（重置内容）
- 205状态响应是服务器告诉用户代理应该重置请求发送的文档视图。
- 此响应的目的是清空文档视图表单里的输入框以便用户能输入其他信息。
- 205响应不能包含实体。
206（部分内容）
- 服务器已经完成了客户端对部分资源的GET请求，请求里面会有Range头部，用来指明请求的范围。并且也可能包含一个If-Range头部来使请求成为一个条件请求。
- 206响应包含以下头部：
- Content-Range头部，用来指明响应的范围。或者Multipart/byteranges的Content-type头部并且每部分包含Content-Range头部。如果响应里出现了Content-Length，那Content-Length的值必须是实际传输的消息主体的字节数。
- Date头部
- ETag和Content-Location
- Expire、Cache-Control和Vary头部
- 如果206响应是使用了强缓存的If-Range的请求结果，那么此响应不应该包含其他的实体头部。如果响应是使用了弱缓存的If-Range请求结果，那么响应必须不能包含其他的实体头部。这能防止缓存的实体主体与更新头部之间的不一致性。
- 响应必须包含相同请求响应为200的所有实体头部。
- 如果ETag或Last-Modified不能精确匹配，不能把206响应和以前的缓存内容合并。
- 一个不能支持Range和Content-Range的缓存不能缓存206响应。
代表重新定向的3xx
- 这类状态码表示用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动执行也不需要用户的交互，并且进一步动作请求的方法必须为GET或HEAD。
- 一个客户端可以发送无限发送能重定向的请求，这种行为可能会产生网络拥挤。
（之前规范版本建议一个客户端最多能有5个重定向请求。因此开发者需要注意客户端可能存在这种闲置）
300（多个选择）
- 请求资源时，在不是HEAD请求时，响应包含一个实体，这个实体包含一个资源特性和位置列表。从这个列表里，用户或用户代理能选择最合适的资源的行为。
- 实体格式被Content-Type头部里的媒体类型指定。用户代理选择最合适的行为可能会被自动执行。这依赖于实体格式和自己的能力。
- 如果服务器能确定合适的行为，表现为在Location头部中包含一个特定URI来表现资源的位置。用户代理可能会利用这个Location自动重定向。
- 300响应是可缓存的。
301（永久移动）
- 请求资源被赋予一个新的永久的URI，那么任何将来对此资源的引用都会利用此301状态响应返回的URI。
- 新的永久URI应该是Location头部的值。除非请求方法是HEAD，响应应该包含一个超文本提示和一个指向新URI的超文本链接。
- 如果客户端接受了一个来自非GET或HEAD请求方法的301响应，那么用户代理不能自动重定向，除非它能被用户确认，因为可能会改变请求提交的条件。
- 当客户端在接收了301状态码响应后，会重定向POST请求，一些已经存在的HTTP/1.0用户代理会错误地把这个请求变成一个GET请求。
302（被发现）
- 请求的资源暂时地存放在一个不同的URI下。因为重定向的地址可能有时会被改变。
- 302响应只有Cache-Control或Expires头部指明的情况下才被缓存。
- 临时的URI应该在Location中指定。除非请求方法是HEAD，否则响应应该包含一个超文本提示和一个指向新URI的超文本链接。
- 如果客户端接受了一个来自非GET或HEAD请求方法的301响应，那么用户代理不能自动重定向，除非它能被用户确认，因为可能会改变请求提交的条件。
- 规范中规定客户端不能在重定向请求的时候改变请求方法，但是大多数用户代理会把302响应看成是303响，从而根据Location头部的URI值执行GET请求，不管原始的请求方法是什么。
- 303和307状态响应的目的是让服务器明白客户端期望那种类型的重定向。
303（查看其它）
- 请求的响应被放在一个不同的URI下，并且应该用GET方法获得那个资源。此方法的存在主要是让POST调用脚本的输出能使用户代理重定向到一个选择的资源。新的URI并不是原始请求资源的代替引用。303响应不能被缓存，但是再次重定向请求的响应应该被缓存。
- 不同的URI应在Location头部里指定。除非请求方法是HEAD，否则次响应应该包含一个超文本提示和一个指向新URI的超文本链接。
- 许多HTTP/1.1以前版本的用户代理不能理解303状态响应。当这些客户端比较关注于交互操作性的时候，302状态码应该被代替利用。因为大多用户代理对302响应的理解就是303响应。
304（没有改变Not Modified）
- 如果客户端已经执行了条件GET请求，并且访问服务器的资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该响应这个状态码。
- 304响应不包含消息主体。
- 响应必须包含以下头部：
- Date：如果时钟不准确的源服务器遵循了这些规则，并且代理和刻画段接收了一个没有Date头部的响应后加上了自己的Date，缓存会正常工作。
- ETag/Content-Location：如果这些在相同请求响应为200的响应里出现。
- Expire，Cache-Control/Vary：如果这些头部值与以前同一变量响应中的不一致。
- 如果条件GET请求使用强缓存时，那么响应不应该包含其他实体头部。当条件GET使用弱缓存时，那么响应必须不能包含其他实体头部，能防止缓存的试题主体与更新的头部之间的不一致性。
- 如果一个304响应指示了一个没有被缓存的试题，那么此缓存必不会理会这个响应，并且以无条件请求重试请求。
- 如果缓存利用一个接收到的304响应去更新缓存项，那么缓存必须用此响应里任何最新的域值更新缓存项。
305（使用代理）
- 请求资源必须能通过代理访问，代理的地址在响应的Location头部里指定。
- Location头部指定了代理的URI。接收者被期望通过代理重试此请求，305响应应该是源服务产生的。
- （规范中没有说明305响应一定是重定向一个单独请求并且只能从源服务器产生）
306（没有使用）
- 306状态码用于之前的版本，不再使用，并且此状态码保留。
307（临时重发）
- 请求的资源临时存在于一个不同的URI下。由于重定向有时会改变，所以客户端为了之后的请求，应该继续利用此请求的URI。307响应只有被Cache-Control或Expire头部指明时才能被缓存。
- 临时URI应在响应的Location头部里给出。否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。因为许多HTTP/1.1以前的用户代理不能理解307状态响应。因此，提示应包含用户在新的URI上重试原始请求的必需信息。
- 如果307状态响应对应的请求方法不是GET或HEAD，那么用户代理不能自动重定向此请求除非能被用户确认，因为这可能会改变请求提交的条件。
代表客户端错误的4xx
- 状态码4xx类的目的是为了指明客户端出现错误的情况。除了当响应HEAD请求，服务器应该包含实体。实体中包含错误请求的解释。
- 此状态码对所有请求的方法都是适合的。
- 用户代理应该展示任何响应里包含的实体用户。
- 如果客户端发送数据，使用TCP协议的服务器应该在关闭连接之前，确保客户端响应接收到了包。
400（Bad Request）
- 因为请求中包含错误的语法，从而不能被服务器理解。
- 客户端在这种情况下不应该重试请求。
401（未授权）
- 服务器需要对请求进行用户认证。响应必须包含一个www-authenticate头部。这个头部包含一个用来请求资源的授权邀请。客户端会以一个authorization头部重试请求。如果请求里包含了授权证书，那么401响应指明对这些证书的授权失败。如果401响应包含一个和之前的响应一样的授权邀请，并且用户代理已经尝试至少一次的授权，那么用户应该放到响应的实体里，这些实体可能包含相关的诊断信息。
402（保留的状态码）
- 为将来的应用保留的状态码
403（禁用）
- 服务器理解请求，但拒绝满足请求。
- 认证是没有作用的，并且请求不应该重试。
- 如果请求方法是HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器应该在响应实体里描述拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么会使用404状态码。
404（没有找到）
- 服务器没有找到任何可以匹配请求URI的资源。但是没有标明是暂时的还是永久的。
- 当服务器不希望精确指出请求为何被拒绝或者没有其他响应可用时，通常会使用这个状态码。
405（方法不被允许）
- 表示请求行里的方法对要请求的资源来说是不被允许的。
- 响应必须包含一个Allow头部，这个头部包含一系列对此请求资源有效的方法。
406（不可接受的）
- 根据客户端请求的Accept和Accept-头部，服务器不能产生让客户端可以接受的响应。
- 如果响应是不可接受的，用户代理应该暂时停止剩余数据的接收兵询问用户的进一步操作。
407（需要代理验证）
- 与401相似，但是要求客户端首先必须利用代理对自己验证。代理必须返回一个proxy-authenticate头部。这个头部会包含一个适用于代理的授权邀请。客户端可能会用一个合适的proxy-authenticate头部重试请求。
408（请求超时）
- 客户端在服务器等待的时间里不能产生请求。
- 客户端可能在以后会重试此请求。
409（冲突）
- 由于和当前资源的状态冲突，请求不能完成。
- 此状态码只被允许出现在期望用户能解决冲突并且能重新提交请求的情况下。响应主体应该包含足够的为用户了解资源冲突的信息。
- 理想情况下，响应实体应该包含足够为用户或用户代理解决问题的信息。
- 冲突最可能发生在响应PUT请求的时候。
410（不存在）
- 请求的资源在源服务器上不可访问并且也没有转发地址，这个状态被认为是永久的。
- 建议请求这个资源的客户端应该在用户确认后删除请求URI的引用。
- 如果服务器不知道或者不确定是不是永久的，就会用404来代替。
- 410响应是可缓存的，除非有其他的说明。
- 410响应主要的目的是为了web的维护，通过告诉资源的请求方不可访问并且告诉接收的服务器移除那个资源的远程链接。
- 对于有时效性的服务以及不再运行的服务器的资源，410响应是很普遍的，不过需要服务器自己来判断。
411（必须包含长度）
- 服务器拒绝接受请求里没有包含Content-Length头部的请求，客户端可以在添加了Content-Length头部后重试。
- 一个有效的Content-Length值指定了请求消息里的消息主体的长度。
412（先决条件失败）
- 在一个或多个请求头部里指定的先决条件在服务器上返回false时的响应。
- 412响应允许客户端把先决条件放到当前资源的元信息上，这样能防止请求方法被应用于一个非目的性的资源。
413（请求实体太大）
- 服务器拒绝处理请求实体太大的请求，服务器可能会关闭连接防止客户端继续请求。
- 如果条件是暂时的，服务器应该有一个retry-after头部来指明这个条件是暂时的并且告诉客户端应该什么时候重试。
414（请求URI太长）
- 服务器拒绝请求的URI太长以至于服务器不能解析。
415（不被支持的媒体类型）
- 请求的资源不支持请求的试题的格式。
416（请求范围不满足）
- 当请求包含一个Range请求头部，并且请求头部的range-specifier的值和已选资源的extent值不一样，请求中没有包含If-Range请求头部，服务器会返回416响应。
- 当416是在byte-range请求返回时，响应还应该包括一个Content-Range试题头部用来指定已选资源的长度。
417（期望失败）
- Expect请求头部里指定的希望不被服务器响应的条件。
- 如果服务器是带来，那么确定请求不被下一个服务器响应。
服务器错误（5xx）
- 指明服务器处理请求时产生错误或者不能处理请求。
- 除了HEAD清奇，服务器应该返回一个实体来解释错误，以及是否是暂时还是长期的不能处理某类请求。
- 用户带来应该展示实体给用户。
- 可用于任何请求方法。
500（服务器内部错误）
- 服务器在处理请求的时候遇到了一个意外条件，这个条件不能让服务器响应这个请求
501（不能实现）
- 服务器不能处理请求。
- 当服务器不能识别请求方法并且不支持处理请求的资源的时候，501响应很合适
502（无效网关）
- 作为网关或者代理服务器从上游服务器接收了一个无效的响应
503（服务不可获得）
- 由于服务器暂时的过载或者维护或者服务器拒绝了连接，服务器不能处理请求。
- 这个响应表示服务不能处理请求是暂时的，将会在一段时间后可以处理请求。
- 如果指定了retry-after值，代表可以在一定时间后重试，如果没有这个头部，客户端应该像处理500一样处理503。
504（网关超时）
- 作为网关或代理的服务器不能及时地接收一个从URI指定的上有服务器或者其他辅助性服务器的响应。
505（HTTP版本不支持）
- 服务器不能支持或拒绝支持当前HTTP协议版本的消息。
- 505指明服务器不能或者不愿意完成当前的请求。
- 505会在相应中包含一个实体，描述为什么当前协议版本不支持以及其他能被服务器支持的协议版本。
