# HTTP状态码
HTTP 状态码用来表示指定的 HTTP 请求是否已成功完成。响应分为五类:信息响应、成功响应,重定向、客户端错误和服务器错误
参考:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/100 (opens new window)
# 100 Continue
HTTP 100 Continue 信息型状态响应码表示目前为止一切正常,客户端应该继续请求,如果已完成请求则忽略。
为了让服务器检查请求的首部,客户端必须在发送请求实体前,在初始化请求中发送 Expect: 100-continue 首部并接收 100 Continue 响应状态码。
# 101 Switching Protocol
HTTP 101 Switching Protocol(协议切换)状态码表示服务器应客户端升级协议的请求(Upgrade (en-US)请求头)正在切换协议。
服务器会发送一个Upgrade (en-US)响应头来表明其正在切换过去的协议。 该过程在协议升级机制(Protocol upgrade mechanism)中详细描述。
# 200 OK
状态码 200 OK 表明请求已经成功。默认情况下状态码为 200 的响应可以被缓存。
不同请求方式对于请求成功的意义如下:
- GET: 已经取得资源,并将资源添加到响应的消息体中。
- HEAD: 响应的消息体为头部信息。
- POST: 响应的消息体中包含此次请求的结果。
- TRACE: 响应的消息体中包含服务器接收到的请求信息。
- PUT 和 DELETE 的请求成功通常并不是响应200 OK的状态码而是 204 No Content 表示无内容(或者 201 Created表示一个资源首次被创建成功)。
# 201 Created
在 HTTP 协议中,201 Created 是一个代表成功的应答状态码,表示请求已经被成功处理,并且创建了新的资源。新的资源在应答返回之前已经被创建。同时新增的资源会在应答消息体中返回,其地址或者是原始请求的路径,或者是 Location 首部的值。
这个状态码的常规使用场景是作为 POST 请求的返回值。
# 202 Accepted
响应状态码 202 Accepted 表示服务器端已经收到请求消息,但是尚未进行处理。但是对于请求的处理却是无保证的,即稍后无法通过 HTTP 协议给客户端发送一个异步请求来告知其请求的处理结果。这个状态码被设计用来将请求交由另外一个进程或者服务器来进行处理,或者是对请求进行批处理的情形。
# 203 Non-Authoritative Information
在 HTTP 协议中,响应状态码 203 Non-Authoritative Information 表示请求已经成功被响应,但是获得的负载与源头服务器的状态码为 200 (OK) 的响应相比,经过了拥有转换功能的 proxy(代理服务器)的修改。
# 204 No Content
HTTP 204 No Content 成功状态响应码,表示该请求已经成功了,但是客户端客户不需要离开当前页面。默认情况下 204 响应是可缓存的。一个 ETag 标头包含在此类响应中。
# 205 Reset Content
在 HTTP 协议中,响应状态码 205 Reset Content 用来通知客户端重置文档视图,比如清空表单内容、重置 canvas 状态或者刷新用户界面。
# 206 Partial Content
HTTP 206 Partial Content 成功状态响应代码表示请求已成功,并且主体包含所请求的数据区间,该数据区间是在请求的 Range 首部指定的。
如果只包含一个数据区间,那么整个响应的 Content-Type 首部的值为所请求的文件的类型,同时包含 Content-Range 首部。
如果包含多个数据区间,那么整个响应的 Content-Type 首部的值为 multipart/byteranges ,其中一个片段对应一个数据区间,并提供 Content-Range 和 Content-Type 描述信息。
# 301 Moved Permanently
HTTP 301 Moved Permanently 说明请求的资源已经被移动到了由 Location 头部指定的 url 上,是固定的不会再改变。搜索引擎会根据该响应修正。
提示
备注: 尽管规范要求浏览器在收到该响应并进行重定向时不应该修改 http method 和 body,但并非所有的用户代理都符合此要求。所以最好将 301 状态码用作 GET 或 HEAD 方法的响应,而对于 POST 则改用 308 Permanent Redirect,因为此状态码会禁止更改请求方法。
# 示例
客户端请求
GET /index.php HTTP/1.1
Host: www.example.org
服务端响应
HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
# 302 Found
HTTP 302 Found 重定向状态码表明请求的资源被暂时的移动到了由该 HTTP 响应的响应头 Location 指定的 URL 上。浏览器会重定向到这个 URL,但是搜索引擎不会对该资源的链接进行更新 (In SEO-speak, it is said that the link-juice is not sent to the new URL)。
即使规范要求浏览器在重定向时保证请求方法和请求主体不变,但并不是所有的用户代理都会遵循这一点,你依然可以看到有缺陷的软件的存在。所以推荐仅在响应 GET 或 HEAD 方法时采用 302 状态码,而在其他时候使用 307 Temporary Redirect 来替代,因为在这些场景下方法变换是明确禁止的。
在确实需要将重定向请求的方法转换为 GET的场景下,可以使用 303 See Other。例如在使用 PUT 方法进行文件上传操作时,需要返回确认信息(例如“你已经成功上传了 xyz”)而不是上传的资源本身,就可以使用这个状态码。
# 303 See Other
HTTP 303 See Other 重定向状态码,通常作为 PUT 或 POST 操作的返回结果,它表示重定向链接指向的不是新上传的资源,而是另外一个页面,比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。
# 304 Not Modified
HTTP 304 Not Modified 说明无需再次传输请求的内容,也就是说可以使用缓存的内容。这通常是在一些安全的方法(safe),例如GET 或HEAD 或在请求中附带了头部信息: If-None-Match 或If-Modified-Since。
如果是 200 OK ,响应会带有头部 Cache-Control, Content-Location, Date, ETag, Expires,和 Vary.
# 307 Temporary Redirect
HTTP 307 Temporary Redirect,临时重定向响应状态码,表示请求的资源暂时地被移动到了响应的 Location 首部所指向的 URL 上。
原始请求中的请求方法和消息主体会在重定向请求中被重用。在确实需要将重定向请求的方法转换为 GET 的场景下,可以考虑使用 303 See Other 状态码。例如,在使用 PUT 方法进行文件上传操作时,如果需要返回一条确认信息(例如“你已经成功上传了 XYZ”),而不是返回上传的资源本身,就可以使用这个状态码。
状态码 307 与 302 之间的唯一区别在于,当发送重定向请求的时候,307 状态码可以确保请求方法和消息主体不会发生变化。如果使用 302 响应状态码,一些旧客户端会错误地将请求方法转换为 GET:也就是说,在 Web 中,如果使用了 GET 以外的请求方法,且返回了 302 状态码,则重定向后的请求方法是不可预测的;但如果使用 307 状态码,之后的请求方法就是可预测的。对于 GET 请求来说,两种情况没有区别。
# 308 Permanent Redirect
在 HTTP 协议中, 308 Permanent Redirect(永久重定向)是表示重定向的响应状态码,说明请求的资源已经被永久的移动到了由 Location 首部指定的 URL 上。浏览器会进行重定向,同时搜索引擎也会更新其链接(用 SEO 的行话来说,意思是“链接汁”(link juice)被传递到了新的 URL)。
在重定向过程中,请求方法和消息主体不会发生改变,然而在返回 301 状态码的情况下,请求方法有时候会被客户端错误地修改为 GET 方法。
# 400 Bad Request
超文本传输协议(HTTP)400 Bad Request 响应状态码表示服务器因某些被认为是客户端错误的原因(例如,请求语法错误、无效请求消息格式或者欺骗性请求路由),而无法或不会处理该请求。
警告
客户端不应该在未进行修改的情况下重复发送此请求。
# 401 Unauthorized
状态码 401 Unauthorized 代表客户端错误,指的是由于缺乏目标资源要求的身份验证凭证,发送的请求未得到满足。
这个状态码会与 WWW-Authenticate 首部一起发送,其中包含有如何进行验证的信息。
这个状态类似于 403,但是在该情况下,依然可以进行身份验证。
# 402 Payment Required
提示
实验性: 这是一项实验性技术 在将其用于生产之前,请仔细检查浏览器兼容性表格。
402 Payment Required 是一个被保留使用的非标准客户端错误状态响应码。
有时,这个状态码表明直到客户端付费之后请求才会被处理。402 状态码被创建最初目的是用于数字现金或微型支付系统,表明客户端请求的内容只有付费之后才能获取。目前还不存在标准的使用约定,不同的实体可以在不同的环境下使用。
# 403 Forbidden
状态码 403 Forbidden 代表客户端错误,指的是服务器端有能力处理该请求,但是拒绝授权访问。
这个状态类似于 401,但进入 403状态后即使重新验证也不会改变该状态。该访问是长期禁止的,并且与应用逻辑密切相关(例如没有足够的权限访问该资源)。
# 404 Not Found
HTTP 响应状态码 404 Not Found 指的是服务器无法找到所请求的资源。返回该响应的链接通常称为坏链(broken link)或死链(dead link),它们会导向链接出错处理(link rot)页面。
404 状态码并不能说明请求的资源是临时还是永久丢失。如果服务器知道该资源是永久丢失,那么应该返回 410(Gone)而不是 404。
# 405 Method Not Allowed
状态码 405 Method Not Allowed 表明服务器禁止了使用当前 HTTP 方法的请求。
# 406 Not Acceptable
HTTP 协议中的 406 Not Acceptable 状态码表示客户端错误,指代服务器端无法提供与 Accept-Charset 以及 Accept-Language 消息头指定的值相匹配的响应。
主动内容协商标头包括:
- Accept
- Accept-Encoding
- Accept-Language 实际上,这种错误极少使用。服务器不应使用此错误代码响应,因为它对终端用户来说很难理解和修复,而是忽略相关的标头并向用户提供实际页面。假设即使用户不完全满意,他们也会更喜欢这种情况,而不是错误代码。
如果服务器返回了这个错误状态码,那么消息体中应该包含所能提供的资源表现形式的列表,允许用户手动进行选择。
# 407 Proxy Authentication Required
状态码 407 Proxy Authentication Required 代表客户端错误,指的是由于缺乏位于浏览器与可以访问所请求资源的服务器之间的代理服务器(proxy server )要求的身份验证凭证,发送的请求尚未得到满足。
这个状态码会与 Proxy-Authenticate 首部一起发送,其中包含有如何进行验证的信息。
# 408 Request Timeout
响应状态码 408 Request Timeout 表示服务器想要将没有在使用的连接关闭。一些服务器会在空闲连接上发送此信息,即便是在客户端没有发送任何请求的情况下。
服务器应该在此类响应中将 Connection 首部的值设置为 "close",因为 408 意味着服务器已经决定将连接关闭,而不是继续等待。
这类响应出现的比较频繁,源于一些浏览器——例如 Chrome, Firefox 27+, 或者 IE9 等——使用 HTTP 协议中的预连接机制来加速上网体验。同时应该注意到,某些服务器会直接关闭连接,而不发送此类消息。
# 409 Conflict
响应状态码 409 Conflict 表示请求与服务器端目标资源的当前状态相冲突。
冲突最有可能发生在对 PUT 请求的响应中。例如,当上传文件的版本比服务器上已存在的要旧,从而导致版本冲突的时候,那么就有可能收到状态码为 409 的响应。
# 410 Gone
HTTP 410 Gone 说明请求的目标资源在原服务器上不存在了,并且是永久性的丢失。如果不清楚是否为永久或临时的丢失,应该使用404
# 411 Length Required
响应状态码 411 Length Required 属于客户端错误,表示由于缺少确定的Content-Length 首部字段,服务器拒绝客户端的请求。
注意,按照规范,当使用分块模式传输数据的时候, Content-Length 首部是不存在的,但是需要在每一个分块的开始添加该分块的长度,用十六进制数字表示。参见 Transfer-Encoding 获取更多细节信息。
# 412 Precondition Failed
在 HTTP 协议中,响应状态码 412 Precondition Failed(先决条件失败)表示客户端错误,意味着对于目标资源的访问请求被拒绝。这通常发生于采用除 GET 和 HEAD 之外的方法进行条件请求时,由首部字段 If-Unmodified-Since 或 If-None-Match 规定的先决条件不成立的情况下。这时候,请求的操作——通常是上传或修改文件——无法执行,从而返回该错误状态码。
# 413 Content Too Large
HTTP 响应状态码 413 Content Too Large 表示请求主体的大小超过了服务器愿意或有能力处理的限度,服务器可能会关闭连接或返回 Retry-After 标头字段。
在 RFC 9110 标准之前,该响应的短语为 Payload Too Large,它仍在被广泛使用。
# 414 URI Too Long
响应码 414 URI Too Long 表示客户端所请求的 URI 超过了服务器允许的范围。
以下是造成这种罕见情况的几种可能原因:
- 当客户端误将 POST 请求当作 GET 请求时,会带有一个较长的查询字符串 (query);
- 当客户端堕入重定向循环黑洞时,例如,指向自身后缀的重定向 URI 前缀 (a redirected URI prefix that points to a suffix of itself);
- 当客户端对服务器进行攻击,试图寻找潜在的漏洞时。
# 429 Too Many Requests
在 HTTP 协议中,响应状态码 429 Too Many Requests 表示在一定的时间内用户发送了太多的请求,即超出了“频次限制”。
在响应中,可以提供一个 Retry-After 首部来提示用户需要等待多长时间之后再发送新的请求。
# 500 Internal Server Error
在 HTTP 协议中,500 Internal Server Error 是表示服务器端错误的响应状态码,意味着所请求的服务器遇到意外的情况并阻止其执行请求。
这个错误代码是一个通用的“万能”响应代码。有时候,对于类似于 500 这样的错误,服务器管理员会更加详细地记录相关的请求信息来防止以后同样错误的出现。
# 501 Not Implemented
HTTP 501 Not Implemented 服务器错误响应码表示请求的方法不被服务器支持,因此无法被处理。服务器必须支持的方法(即不会返回这个状态码的方法)只有 GET 和 HEAD。
请注意,你无法修复 501 错误,需要被访问的 web 服务器去修复该问题。
# 502 Bad Gateway
502 Bad Gateway 是一种 HTTP 协议的服务端错误状态代码,它表示作为网关或代理的服务器,从上游服务器中接收到的响应是无效的。
提示
备注: 网关在计算机网络体系中可以指代不同的设备,502 错误通常不是客户端能够修复的,而是需要由途经的 Web 服务器或者代理服务器对其进行修复。
# 503 Service Unavailable
503 Service Unavailable 是一种 HTTP 协议的服务器端错误状态代码,它表示服务器尚未处于可以接受请求的状态。
通常造成这种情况的原因是由于服务器停机维护或者已超载。注意在发送该响应的时候,应该同时发送一个对用户友好的页面来解释问题发生的原因。该种响应应该用于临时状况下,与之同时,在可行的情况下,应该在 Retry-After 首部字段中包含服务恢复的预期时间。
缓存相关的首部在与该响应一同发送时应该小心使用,因为 503 状态码通常应用于临时状况下,而此类响应一般不应该进行缓存。
# 504 Gateway Timeout
504 Gateway Timeout 是一种 HTTP 协议的服务器端错误状态代码,表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应。
Gateway(网关)在计算机网络体系中可以指代不同的设备,504 错误通常不是在客户端可以修复的,而是需要由途径的 Web 服务器或者代理服务器对其进行修复。
# 505 HTTP Version Not Supported
505 HTTP Version Not Supported 是一种 HTTP 协议的服务器端错误状态代码,表示服务器不支持请求所使用的 HTTP 版本。
# 507 Insufficient Storage
HTTP 协议的 507 Insufficient Storage 响应状态码 可以在 WebDAV 协议(基于 web 的分布式创作和版本控制,参见 RFC 4918)中给出。
507 码表示服务器不能存储相关内容。准确地说,一个方法可能没有被执行,因为服务器不能存储其表达形式,这里的表达形式指:方法所附带的数据,而且其请求必需已经发送成功。