HTTP响应状态码（[RFC9110]）-526互联

本内容翻译自[RFC9110]15. Status Codes，不足之处请自行查阅文档。

15. 状态码

响应的状态码是一个三位整数代码，用于描述请求的结果和响应的语义，包括请求是否成功以及附带了什么内容（如果有的话）。所有有效代码的范围为100至599（含599）。

状态码的第一位数字定义了响应的类别，后两位数没有任何分类作用。第一位数字可以是以下5个值：

1xx（信息性）：请求已经被接收，继续处理中
2xx（成功）：请求已被成功地接收、理解和接受
3xx（重定向）：需要采取进一步行动才能完成请求
4xx（客户端错误）：请求包含了错误语法或者无法满足
5xx（服务器错误）：服务器无法满足一个显然合法的请求

HTTP状态码可以被扩展，客户端不需要理解所有注册状态码的含义，虽然这样是很理想的。然而，客户端必须理解任何状态码的类别（如第一个数字所示），将未识别的状态码等同于该类别的x00状态码。

例如，如果客户端接收到一个无法识别的状态码471，它从第一个数字就可以看出它的请求存在问题，并将其视作收到了一个400（错误请求）状态码。响应信息通常会包含一个表述来解释这个状态。

范围100...599以外的值是无效的。在实践中，通常使用该范围之外的三位整数值（即600...999），用于非HTTP状态（如库错误）的内部通信。客户端如果接收到带有无效状态码的响应，应将其视作状态码5xx（服务器错误）的响应进行处理。

一个请求可以有多个相关的响应：0个或多个状态码在“信息性”（1xx）范围内的“临时”（非最终）的响应，然后是一个状态码在其他范围内的“最终”响应。

15.1 状态码概览

本规范定义了下列状态码。这里列出的原因短语只是推荐用语——它们可以被地方性的相应短语替代或完全忽略，而不会影响协议。

除非方法定义或者显式地缓存控制，否则那些状态码被定义为启发式高速缓存（如本规范中的200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414和501）的响应可被启发式过期缓存重复使用；所有其他状态码均不是启发式高速缓存。

本规范范围之外的其他状态码已被指定在HTTP中使用。所有这些状态码都应在“超文本传输协议（HTTP）状态码注册表”中注册，详见第16.2节。

15.2 信息性1xx

1xx（信息性）这类状态码表示，在完成所请求的操作和发送最终的响应之前，用于传达连接状态或请求进度的临时响应。由于HTTP/1.0没有定义任何1xx状态码，服务器不能向HTTP/1.0客户端发送1xx的状态码。

1xx响应以头部块结束，不能包含内容或者内容预告。

客户端必须能够在收到最终响应之前，解析接收到的一个或多个1xx响应，即使客户端并不想收到1xx响应。用户代理可以忽略掉意料之外的1xx响应。

代理必须转发1xx响应，除非代理自身请求生成1xx响应。比如说，假设代理在转发请求时添加了“Expect: 100-continue”头部字段，那它就不需要转发相应的100（继续）响应。

15.2.1 100 继续

100（继续）状态码表示，请求的初始部分已经被接收并且服务器尚未拒绝。服务器预计在完全接收请求并采取相应操作后再发送最终的响应。

当请求带有一个包含了100-continue期望值的“Expect”头部字段时，100响应表示服务器希望接收请求内容，就如第10.1.1节所述。客户端应该继续发送请求，并摒弃100响应。

如果请求不带有包含100-continue期望值的“Expect”头部字段时，客户端可以直接摒弃这个临时响应。

15.5.5 101 切换协议

101（切换协议）状态码表示，服务器理解并且愿意满足客户端通过‘Upgrade’头部字段（第7.8节）提出的更改此连接上使用的应用协议的请求。服务器必须在响应中生成一个Upgrade头部字段，用于表明在此响应后哪些协议将生效。

此处假设服务器只在有利时才同意切换协议。比如说，与旧版本相比，切换到HTTP较新版本可能更有优势，当提供实时同步的资源时，切换到支持此类特性的协议可能会更有优势。

15.3 成功2xx

2xx（成功）这类状态码表示客户端的请求已被成功地接收、理解和接受。

15.3.1 200 好的

200（好的）状态码表示请求成功。200响应中发送的内容取决于请求方法。对于本规范所定义的方法，其内容的预期含义可被概括如下：

请求方法	响应内容所代表的是：
GET	目标资源
HEAD	目标资源，类似于GET，但不传输表示数据
POST	行动的状态或取得的结果
PUT，DELETE	行动的状态
OPTIONS	目标资源的通信选项
TRACE	返回跟踪信息的服务器收到的请求信息

除了对连接的响应，200响应应包含消息内容，除非信息框架明确指出内容长度为零。如果请求的某些方面表明请求成功后不需要内容，则源服务器应替代返回204（无内容）响应。对于连接，没有内容，因为成功的结果就是一条隧道，紧接在200响应头部分之后。

200响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

在对GET或HEAD的200响应中，源服务器应为选定的表征发送任何可用的验证字段（第8.8节），首选同时带上强实体标签和Last-Modified日期值。

在对状态变更的方法的200响应中，响应中发送的任何验证字段（第8.8节）都会传达因成功应用请求语义而形成的新表征的当前验证器。请注意，PUT方法（第9.3.4节）有一些额外的要求，可能不允许发送此类验证器。

15.3.2 201 已创建

201（已创建）状态码表示，请求已经被完成，并已创建一个或多个新资源。请求创建的主资源由响应中的Location头部字段标识，如果没有收到Location头部字段，则由目标URI标识。

201响应内容通常描述并链接到创建的资源。响应中发送的任何验证字段（第8.8节）都会传达请求创建的新表征的当前验证器。请注意，PUT方法（第9.3.4节）有一些额外的要求，可能不允许发送此类验证器。

15.3.3 202 已接受

202（已接受）状态码表示，请求已被接受处理，但处理尚未完成。该请求最终可能会被付诸行动，也可能不会，因为在实际处理时可能会被驳回。HTTP没有从异步操作中重新发送状态码的功能。

202响应故意不做任何表态，其目的是允许服务器接受其他进程（也许是一天只运行一次的批处理型程序）的请求，而不要求用户代理与服务器的连接持续到进程完成。与此响应一起发送的表征应该描述请求的当前状态，并指向（或嵌入）一个状态监控器，以便向用户提供请求的预计完成时间。

15.3.4 203 非权威信息

203（非权威信息）状态码表示，请求成功，但从源服务器的200（好的）响应中附带的内容已被转换代理（第7.7节）修改。该状态码允许代理在应用转换时通知接收方，了解（这个转换）可能会影响之后有关内容的决策。比如，未来对内容的缓存验证请求可能只适用于相同的请求路径（通过相同的代理）。

203响应是启发式缓存；即，除非方法定义或显示的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.3.5 204 无内容

204（无内容）状态码表示，服务器已成功完成请求，并且响应内容中没有额外要发送的内容。响应头字段中的元数据指的是应用请求操作后的目标资源及其选定的表征。

例如，PUT请求收到了204状态码的响应，并且响应包含Etag字段，则表示该PUT请求成功，Etag字段值包含了目标资源的新表征的实体标记。

204响应允许服务器表明已成功将操作应用到目标资源，同时暗示用户代理不需要从其当前的”文档视图“（如果有的话）中跳转。服务器假定，用户代理将根据它自己的接口向用户提供一些成功的提示，并将响应中任何新的或者更新的元数据应用到其活动表示中。

例如，204状态码通常用于与”保存“操作相对应的文档编辑接口，这样被保存的文档仍可供用户编辑。它也常用于那些希望自动传输数据的接口，如分布式版本控制系统。

204响应以头部块结束，不能包含内容或内容预告。

204响应是启发式缓存，即，除非方法定义或显示的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.3.6 205 重置内容

205（重置内容）状态码表示，服务器已满足请求，并且希望用户代理将导致请求发送的”文档视图“重置为从源服务器接收到的原始状态。

此响应旨在支持常见的数据录入用例，即用户接收支持数据录入的内容（表单、记事本、画布等），在该空间中输入或操作数据，使得输入的数据在请求中被提交，然后重置数据录入机制以进行下一次输入，以便用户可以轻松启动另一个输入操作。

因为205状态码意味着不提供额外的内容，因此服务器不能在205响应中生成内容。

15.3.7 206 部分内容

206（部分内容）状态码表示，服务器通过传输选定的表征的一个或多个部分，成功满足了目标资源的范围请求。

支持范围请求（第14节）的服务器通常会尝试去满足所有请求范围，因为发送较少的数据很可能导致客户端再次请求剩余数据。然而，服务器可能出于自身原因（如暂时不可用、缓存效率、负载平衡等），只希望发送所请求数据的子集。由于206响应是自描述性的，客户端仍然可以理解仅部分满足其范围请求的响应。

客户端必须检查206响应的Content-Type和Content-Range字段，以确定包含了哪些部分，以及是否需要额外请求。

生成206响应的服务器必须生成以下头部字段，如果该字段已在对同一请求的200（好的）响应中发送，则还必须生成下文各小节要求的头部字段：Date、Cache-Control、ETag、Expires、Content-Location和Vary。

206响应中的Content-Length头部字段表示该报文内容的八位字节数，通常不是选定的表征的完整长度。每个Content-Range头部字段包含了关于选定的表征的完整长度信息。

发送方对带有If-Range头部字段的请求生成206响应时，不应生成超出其要求的其他表征头部字段，因为客户端先前已经有了包含那些头部字段的响应。否则，发送方必须生成对同一请求的200（好的）响应中发送的所有表征头部字段。

206响应是启发式缓存；即，除非显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.3.7.1 单一部分

如果传输的是单一部分，生成206响应的服务器必须生成Content-Range头部字段，说明选定的表征的范围，以及由该范围组成的内容。例如：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Type: image/gif
... 26012 bytes of partial image data ...

15.3.7.2 多个部分

如果传输的是多个部分，生成206响应的服务器必须生成在第14.6节定义的“multipart/byteranges”内容，以及包含了“multipart/byteranges”媒体类型及其必要边界参数的Content-Type头部字段。为避免和单部分响应混淆，服务器不得在多部分响应的HTTP头部生成Content-Range头部字段（该字段将转而在每个部分中发送）。

在多部分内容中每个主体部分的头部区域内，服务器必须生成一个与该主体部分所包含的范围相对应的Content-Range头部字段。如果选定的表征在200（好的）响应中会有一个Content-Type头部字段，则服务器应在每个主体部分的头部区域生成相同的Content-Type字段。例如：

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range...
--THIS_STRING_SEPARATES--

当多个范围被请求时，服务器可以合并任何重叠的范围，或者被小于发送多个部分开销的间隙分开的范围，而不管相应范围规格在接收到的Range头部字段中出现的顺序。由于“multipart/byteranges”每个部分之间的典型开销约为80字节，具体取决于选定的表征的媒体类型和所选边界参数长度，因此传输许多不相连的小部分可能比传输整个选定的表征的效率要低。

在请求单个范围时，服务器不得生成多部分响应，因为客户端不请求多部分可能是因为不支持多部分响应。然而，在请求多个范围时，发现只有一个范围是可满足的或者在合并后只剩下一个范围，服务器可能生成只有一个主体部分的“multipart/byteranges”响应。无法处理“multipart/byteranges”响应的客户端不得生成要求多个范围的请求。

生成多部分响应的服务器应按照接收到的在Range头部字段中相应范围规格出现的顺序发送各部分，但不包括那些被认为不可满足的或被合并进其他范围的范围。收到多部分响应的客户端必须检查每个主体部分的Content-Range头部字段以确定该主体部分中包含的范围；客户端不能依赖于收到与其请求的范围相同的内容，也不能依赖于收到与其请求的顺序相同的内容。

15.3.7.3 组合部分

如果连接过早关闭或者请求使用了1个或多个范围规格，则响应可能只传输了一个表征的子范围。经过多次这样的传输之后，客户端可能会收到相同表征的多个范围。只有当这些范围具有相同的强验证器（第8.8.1节）时，才能安全地将它们组合在一起。

在客户端收到目标资源上GET请求的多个部分响应后，如果这些响应共享同一个强验证器，则可以将这些响应合并为一个更大的连续范围。

如果最近一次响应是不完整的200（好的）响应，则该响应的头部字段将用于任何组合响应，并取代匹配的已存储响应的头部字段。

如果最近一次响应是206（部分内容）响应，并且至少有一个匹配的已存储响应是200（好的），那么组合响应的头部字段由最近的200响应的头部字段组成。如果所有匹配的已存储响应都是206响应，则使用具有最新头部字段的已存储响应作为组合响应的头部字段来源，但客户端必须使用新响应中提供的其他头部字段（Content-Range除外）来替换已存储响应中相应头部字段的所有实例。

组合响应的内容由新响应中的部分内容范围和所有匹配的已存储响应联合组成。如果这个联合包括整个表征范围，则客户端必须将这个组合响应当作完整的200（好的）响应来处理，包括一个反映完整长度的Content-Length头部字段。否则，客户端必须以下列方式之一处理这个连续范围的集合：如果组合响应是表征的前缀则是不完整的200（好的）响应，包含“multipart/byteranges”内容的单个206（部分内容）响应，或多个206（部分内容）响应，每个响应都由Content-Range头部字段标明一个连续的范围。

15.4 重定向3xx

3xx（重定向）这类状态码表示，用户代理需要采取进一步行动才能完成请求。重定向有以下几种类型：

重定向表示该资源可能在不同的URI上可用，如状态码301（永久性移动）、302（找到）、307（临时重定向）和308（永久重定向）中Location头部字段所提供的信息。
重定向，在能够代表该资源的匹配资源中提供选择，如300（多选）状态码。
重定向到一个由Location头部字段标识的不同的资源，可代表对请求的间接响应，如303（见其他）状态码。
重定向到之前已存储的结果，如304（未修改）状态码。

注：在HTTP/1.0中，状态码301（永久性移动）和302（找到）最初被定义为保留方法（[HTTP/1.0]，第9.3节），以匹配他们在CERN中的实现；303（见其他）则是为将方法改为GET的重定向而定义的。不过，早期的用户代理在将POST请求重定向为POST（根据当时的规范）还是GET（重定向到不同网站时更安全的选择）的问题上存在分歧。流行的做法最终趋向于将方法改为GET。307（临时重定向）和308（永久重定向）[RFC7538]是之后增加的，以明确表示保留方法的重定向，并调整了状态码301和302以允许将POST请求重定向为GET。

如果提供了Location头部字段（第10.2.2节），用户代理可以自动将其请求重定向到Location字段值所引用的URI，即使特定的状态码无法理解。对于第9.2.1节中定义的未知安全与否的方法，自动重定向需要小心谨慎，因为用户可不希望重定向到不安全的请求。

在自动跟踪重定向请求时，用户代理应重新发送原始的请求信息并做如下修改：

将目标URI替换为重定向响应的Location头部字段值相对于原始请求的目标URI解析后引用的URI。
移除由执行时自动生成的头部字段，并根据新请求的情况用更新后的值取代他们。这包括：
1. 特定于连接的头部字段（参见第7.6.1节），
2. 客户端代理配置的特定头部字段，包括（但不限于）Proxy-Authorization，
3. 特定于源的头部字段（如果有），包括（但不限于）Host，
4. 验证实施缓存添加的头部字段（如If-None-Match、If-Modified-Since），以及
5. 特定于资源的头部字段，包括（但不限于）Referer、Origin、Authorization和Cookie。
在有安全影响的情况下，考虑移除不是在执行时自动生成的头部字段（即，请求中出现的那些由调用上下文添加的字段）；包括但不限于Authorization和Cookie。
根据重定向状态码的语义更改请求方法（如果适用）。
如果请求方法更改为GET或HEAD，则移除特定于内容的头部字段，包括（但不限于）Content-Encoding、Content-Language、Content-Location、Content-Type、Content-Length、Digest、Last-Modified。

客户端应检测并干预循环重定向（即，“无限”重定向循环）。

注：本规范的早期版本建议最多进行5次重定向（[RFC2068]，第10.3节）。内容开发者需要注意到有些客户端可能实施了这个固定限制。

15.4.1 300 多选

300（多选）状态码表示，目标资源有不止一种表示形式，每种表示形式都有其更特定的标识，并提供了有关可选的表示形式的信息，以便用户（或用户代理）通过将其请求重定向其到其中一个或多个标识符来选择更偏好的表示形式。换句话说，服务器希望用户代理参与反应式协商，以选择最合适其需求的表示（第12节）。

如果服务器有首选项，服务器应生成一个包含首选项URI引用的Location头部字段。用户代理可以使用Location字段值进行自动重定向。

对于HEAD以外的请求方法，服务器应在300响应中生成包含表征元数据和URI引用的列表的内容，用户或用户代理可以从中选择最偏好的一个。用户代理如果能理解所提供的媒体类型，它可以自动从该列表中做出选择。本规范没有定义自动选择的具体格式，因为HTTP试图保持其内容定义的正交性。在实践中，表征是以被认为用户代理可以接受的某种易于解析的格式（由共享设计或内容协商决定）或某种被普遍接受的超文本格式来提供的。

300响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

注：在300状态码的最初提案中将URI头部字段定义为提供可替代表征的列表，这样它就可用于200、300和406响应，并在对HEAD方法的响应中传输。然而，由于缺乏部署以及对语法的分歧，URI和Alternatives（后来的提案）都从本规范中删除了。可将该列表作为Link头部字段值[RFC8288]（其成员具有“交替”关系）进行通信，尽管部署是一个先有鸡还是先有蛋的问题。

15.4.2 301 永久性移动

301（永久性移动）状态码表示，目标资源已被分配了一个新的永久性URI，之后对该资源的任何引用都应使用所附URI中的一个。服务器建议有链接编辑能力的用户代理使用服务器发送的新引用之一永久性替换对目标URI的引用。然而，除非用户代理正积极编辑引用（比如，参与编写内容），连接是安全的，并且对于被编辑的内容而言源服务器是可信的权威，否则这一建议通常会被忽略。

服务器应在响应中生成一个Location头部字段，其中包含新的永久URI的首选URI引用。用户代理可以将Location字段值用于自动重定向。服务器的响应内容通常包含一个简短的超文本注释，带有指向新URI的超链接。

注：由于历史原因，用户代理可能会将后续请求的请求方法由POST改为GET。如果不希望出现这种行为，可以使用308（永久重定向）状态码来替代。

301响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.4.3 302 找到

302（找到）状态码表示，目标资源暂时位于一个不同的URI下。因为重定向有时可能会改变，客户端应在之后的请求中继续使用目标URI。

服务器应在响应中生成Location头部字段，其中包含不同URI的URI引用。用户代理可以使用Location字段值进行自动重定向。服务器的响应内容通常包含一个简短的超文本注释，带有指向不同URI的超链接。

注：由于历史原因，用户代理可能将后续请求的请求方法由POST改为GET。如果不希望出现这种行为，可以使用307（临时重定向）状态码替代。

15.4.4 303 见其他

303（见其他）状态码表示，服务器正在将用户代理重定向到一个不同的资源，如Location头部字段中的URI所示，其目的在于对原始请求提供间接的响应。用户代理可以针对该URI执行检索请求（如果使用HTTP，则使用GET或HEAD请求），该请求也可能被重定向，并将最终的结果作为对原始请求的应答。请注意，Location头部字段中的新URI并不等同于目标URI。

该状态码可被应用于任何HTTP方法。它主要用于允许POST操作的输出将用户代理重定向到不同的资源，因为这样做可以将与POST响应相对应的信息，作为可单独识别、收藏和缓存的资源。

GET请求的303响应表明，源服务器没有可由服务器通过HTTP传输的目标资源的表征。然而，Location字段值指的是描述目标资源的资源，因此对其他资源发起检索请求可能得到对接收方有用的表征，但这并不意味着它代表了原始目标资源。请注意，对于什么可以被表示、什么表征是充分的、以及什么可能是有用的描述等问题的答案，不属于HTTP的范围。

除了对HEAD请求的响应外，303响应的表征应包含一个简短的超文本注释，并带有链接指向由Location头部字段提供的相同URI引用。

15.4.5 304 未修改

304（未修改）状态码表示，收到了有条件的GET或HEAD请求，如果不是因为该条件的评估结果为假的话，应得到200（好的）响应。换而言之，服务器不需要传输目标资源的表征，因为该请求表明发起条件请求的客户端，已经拥有有效的表征；因此服务器正在重定向客户端，让其使用已存储的表征，就像使用200（好的）响应的内容一样。

生成304响应的服务器必须生成对同一请求的200（好的）响应中发送的以下任何头部字段：

Content-Location、Date、ETag和Vary
Cache-Control和Expires（见「缓存」）

由于304响应的目的在于当接收方已经有一个或多个缓存的表征时减少信息传输，因此发送方不应生成除上述所列字段以外的表征元数据，除非所述元数据是为指导缓存更新而存在的（例如，如果响应没有ETag字段，则Last-Modified可能有用）。

对收到304响应的高速缓存的要求在「缓存」的第4.3.4节中有定义。如果条件请求是由出站客户端发出的，比如用户代理使用自己的缓存向共享代理发送条件GET，则该共享代理应将304响应转发给该客户端。

304响应以头部块结束；不能包含内容或内容预告。

15.4.6 305 使用代理

305（使用代理）状态码在本规范的上一版本中定义，现已废弃（[RFC7231]附录B）。

15.4.7 306（未使用）

306状态码在本规范的上一版本中定义，已不再使用，该代码为保留代码。

15.4.8 307 临时重定向

307（临时重定向）状态码表示，目标资源暂时位于一个不同的URI下，客户代理在执行自动重定向到该URI时，不得更改请求方法。由于重定向会随着时间的推移而改变，客户端应在之后的请求中继续使用原始目标URI。

15.4.9 308 永久重定向

308（永久重定向）状态码表示，目标资源已被分配了一个新的永久URI，之后对该资源的任何引用都应使用所附的URI中的一个。服务器建议具有链接编辑能力的用户代理使用服务器发送的新引用之一永久性替换对目标URI的引用。然而，除非用户代理正在积极编辑引用（如，参与编写内容）、连接是安全的，并且对于被编辑的内容而言源服务器是可信任的权威，否则这一建议通常会被忽略。

服务器应在响应中生成Location头部字段，其中包含新的永久URI中的首选URI引用。用户代理可使用Location字段值进行自动重定向。服务器的响应内容通常包含一个简洁的超文本链接，带有指向新URI的超链接。

308响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

注：该状态码比其他同类状态码更新（2014年6月），因此可能无法在所有地方被识别。有关部署注意事项，请参阅[RFC7538]第4节。

15.5 客户端错误4xx

4xx（客户端错误）类状态码表示，客户端似乎出错了。除响应HEAD请求外，服务器应发送一个包含错误情况的解释的表征，并说明该错误是暂时的还是永久的。这类状态码适用于任何请求方法。用户代理应向用户展示任何包含的表征。

15.5.1 400 坏请求

400（坏请求）状态码表示，服务器无法或不会处理请求，因为某些东西被认为是客户端错误（比如，请求语法畸形、请求信息框架无效，或是欺骗性请求路由）。

15.5.2 401 未授权

401（未授权）状态码表示，因为缺乏对目标资源的有效身份验证凭据，请求未被应用。生成401响应的服务器必须发送WWW-Authenticate头部字段（第11.6.1节），并包含至少一个适用于目标资源的质疑。

如果请求包含了身份验证凭据，则401响应表示拒绝对这些凭据授权。用户代理可以使用新的或者替换过的Authorization头部信息（第11.6.2节）来重新发送请求。如果401响应包含了与之前响应相同的质疑，且用户代理已至少尝试验证过一次，则用户代理应向用户呈现所附的表征，因为它通常包含相关的诊断信息。

15.5.3 402 需付款

402（需付款）状态码被保留以供将来使用。

15.5.4 403 禁止

403（禁止）状态码表示，服务器理解该请求但拒绝满足。如果服务器希望公开请求为什么被禁止，可以在响应内容（如果有）中对原因进行描述。

如果请求提供了身份验证凭据，服务器则认为这些凭据不足以允许访问。客户端不应使用相同的凭据自动重复请求。客户端可以使用新的或者不同的凭据以重复请求。然而，请求可能是因为与凭据无关的原因而被禁止。

希望“隐藏”被禁止的目标资源的当前存在的源服务器，可使用404（未找到）状态码来响应。

15.5.5 404 未找到

404（未找到）状态码表示，源服务器未找到目标资源的当前表征，或不愿意透露它的存在。404状态码不能表明表征的缺失是暂时的还是永久的；如果源服务器知道（可能通过某种可配置的手段）这种情况是永久的，那就更偏好410（消失）状态码而不是404。

404状态码是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.5.6 405 方法不允许

405（方法不允许）状态码表示，从请求行中接收到的方法为源服务器所知，但不受目标资源支持。源服务器必须在405响应中生成Allow头部字段，其中包含目标资源当前支持的方法列表。

405响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.5.7 406 不可接受

406（不可接受）状态码表示，根据请求中收到的主动协商头部字段（第12.1节），目标资源没有可被用户代理接受的当前表征，并且服务器不愿意提供默认表征。

服务器应生成包含可用的表征特性和相应资源标识符列表的内容，用户或用户代理可从列表中选择最合适的表征特性。用户代理可以自动选择该列表中最合适的选项。但是，本规范并没有为这种自动选择定义任何标准，如第15.4.1节中所描述。

15.5.8 407 需要代理身份验证

407（需要代理身份验证）状态码与401（未授权）类似，但它表示客户端需要自己去进行身份验证才能使用代理处理此请求。代理必须发送Proxy-Authenticate头部字段（第11.7.1节），其中包含适用于处理该请求的代理的质疑。客户端可使用新的或替换的Proxy-Authorization头部字段（第11.7.2节）去重复该请求。

15.5.9 408 请求超时

408（请求超时）状态码表示，服务器在预计等待的时间内没有收到完整的请求信息。

如果客户端有一个未完成的请求正在传输中，它可以重复该请求。如果当前连接不可用（例如，在HTTP/1.1中由于请求分界丢失而无法使用），则将使用新的连接。

15.5.10 409 冲突

409（冲突）状态码表示，因为与目标资源的当前状态发生冲突，请求无法完成。该代码用于在用户可能有能力去解决冲突并重新提交请求的情况。服务器应生成包含足够信息的内容，以便用户去识别冲突源。

冲突更可能发生在对PUT请求的响应中。比如，如果使用了版本控制，PUT表征包含的对资源的更改与之前（第三方）请求的更改相冲突，则源服务器可能使用409响应来表示无法完成请求。在这种情况下，响应表征很可能包含有用的信息，以便基于修订历史合并差异。

15.5.11 410 消失

410（消失）状态码表示，在源服务器上已无法访问目标资源，并且这种情况很可能是永久性的。如果源服务器不知道或者无法确定这种情况是否是永久的，应替换使用404（未找到）状态码。

410响应主要用于协助网页维护任务，通知接收方该资源故意不可用，服务器所有者希望指向该资源的链接被删除。这种情况常见于限时推广服务，以及属于不再与源服务器站点有关联的个人的资源。没必要将所有永久不可用的资源都标记为“消失”，也没必要将标记保留多久——这由服务器所有者自行决定。

410响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.5.12 411 需要长度

411（需要长度）状态码表示，服务器拒绝接受未定义Content-Length（第8.6节）的请求。客户端如果添加了包含请求内容长度的有效Content-Length头部字段，则可以重新请求。

15.5.13 412 预设条件失败

412（预设条件失败）状态码表示，请求头字段中给出的一个或多个条件在服务器上测试时结果为假（第13节）。该响应状态码允许客户端对当前资源状态（其当前表征和元数据）设置预设条件，从而防止当目标资源处于意外状态时应用请求方法。

15.5.14 413 内容过大

413（内容过大）状态码表示，服务器拒绝处理请求，因为请求内容超出了服务器愿意或者能够处理的范围。如果使用的协议版本允许，服务器可以终止请求；否则，服务器可以关闭连接。

如果情况是暂时的，服务器应该生成一个Retry-After头部字段来表明情况是暂时的，以及客户端可以在多长时间后再次尝试。

15.5.15 414 URI过长

414（URI过长）状态码表示，服务器拒绝为请求提供服务，因为目标URI超出了服务器愿意解释的长度。这种罕见的情况只有在以下情况中才可能发生：客户端不恰当地将POST请求转换为带有较长query信息的GET请求；客户端陷入重定向的无限循环（如，重定向URI的前缀指向其自身的后缀）；或者服务器受到试图利用潜在的安全漏洞的客户端的攻击。

414响应是启发式缓存；即，除非方法定义或显式的缓存控制（参见「缓存」第4.2.2节）另有说明。

15.5.16 415 不支持的媒体类型

415（不支持的媒体类型）状态码表示，源服务器拒绝为请求提供服务，因为内容格式不被请求该目标资源时使用的方法支持。

格式问题可能是由于请求声明的Content-Type或者Content-Encoding导致的，或是直接检查数据的结果。

如果问题是由不支持的内容编码造成的，则应使用Accept-Encoding响应头字段（第12.5.3节）来指明请求中本应被接受的内容编码（如果有的话）。

另一方面，如果是由于不支持的媒体类型造成的，则可使用Accept响应头字段（第12.5.1节）来说明请求中本应被接受的媒体类型。

15.5.17 416 范围无法满足

416（范围无法满足）状态码表示，请求的Range头部字段（第14.2节）中的范围集被拒绝了，原因是请求的范围全都无法满足，或是客户端请求了过多的小范围或者重叠范围（潜在的拒绝服务攻击）。

每个范围单元都定义了自身范围集的可满足性要求。例如，第14.1.2节定义了字节范围集的可满足性。

对字节范围的请求生成了416响应的服务器应生成Content-Range头部字段，指定选定的表征的当前长度（第14.4节）。

比如：

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

注：由于服务器可以自由忽略Range，因此许多实现中会在200（好的）响应中回复整个选定的表征。一方面是因为大多数客户端都准备好接收200（好的）以完成任务（尽管效率不高），另一方面是因为客户端不会停止无效的范围请求直到它们收到完整的表征。因此，即使在最合适的情况下，客户端也不能依赖于接收416（范围无法满足）响应。

15.5.18 417 预期失败

417（预期失败）状态码表示，至少有一个入站服务器无法满足请求的Expect头部字段（第10.1.1节）中给出的期望。

15.5.19 418（未使用）

[RFC2324]是一个4月1日的RFC，讽刺了各种滥用HTTP的方式；滥用方式之一就是定义了特定于应用程序的418状态码，这已经成了一个笑话，因为这个代码已经无法在未来的用途中使用。

因此，418状态码被保留在IANA HTTP状态码注册表中。这表示该状态码目前不能被分配给其他应用程序。如果未来有情况需要使用该状态码（比如，4NN状态码用尽了），则可以将其重新分配给其他用途。

15.5.20 421 误发请求

421（误发请求）状态码表示，请求指向的是无法或不愿为目标URI生成权威响应的服务器。源服务器（或者代表源服务器的网关）发送421以拒绝与服务器已配置的源不匹配（第4.3.1节），或是与接收请求的连接上下文不匹配的目标URI（第7.4节）。

收到421（误发请求）响应的客户端可以通过不同的连接（比如目标资源来源的特定新连接），或是通过替代服务[ALTSVC]再次请求（无论请求方法是否幂等）。

代理不得生成421响应。

15.5.21 422 无法处理的内容

422（无法处理的内容）状态码表示，服务器理解请求内容的内容类型（因此不适合使用415（不支持的媒体类型）状态码），并且请求内容的语法也是正确的，但是无法处理其中包含的指令。例如，如果XML请求内容包含格式良好（即，语法正确）但语义错误的XML指令，就可以发送该状态码。

15.5.22 426 需要升级

426（需要升级）状态码表示，服务器拒绝使用当前协议执行请求，但在客户端升级到不同协议后可能愿意执行请求。服务器必须在426响应中发送Upgrade头部字段来表明所需协议（第7.8节）。

例如：

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.