HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端 的处理是否正常、通知出现的错误等工做。浏览器
响应的状态码可描述请求的处理结果,状态码如 200 OK,以 3 位数字和缘由短语组成。服务器
数字中的第一位指定了响应类别,后两位无分类。响应类别有如下 5 种。cdn
只要遵照状态码类别的定义,即便改变 RFC2616 中定义的状态码, 或服务器端自行建立状态码都没问题。blog
2XX 的响应结果代表请求被正常处理了。资源
表示从客户端发来的请求在服务器端被正常处理了。 在响应报文内,随状态码一块儿返回的信息会因方法的不一样而发生改 变。好比,使用 GET 方法时,对应请求资源的实体会做为响应返 回;而使用 HEAD 方法时,对应请求资源的实体首部不随报文主体 做为响应返回(即在响应中只返回首部,不会返回实体的主体部 分)。it
该状态码表明服务器接收的请求已成功处理,但在返回的响应报文中 不含实体的主体部分。另外,也不容许返回任何实体的主体。好比, 当从浏览器发出请求处理后,返回 204 响应,那么浏览器显示的页面 不发生更新。 通常在只须要从客户端往服务器发送信息,而对客户端不须要发送新信息内容的状况下使用。io
该状态码表示客户端进行了范围请求,而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。class
3XX 响应结果代表浏览器须要执行某些特殊的处理以正确处理请 求。服务器端
永久性重定向。该状态码表示请求的资源已被分配了新的 URI,之后 应使用资源如今所指的 URI。也就是说,若是已经把资源对应的 URI 保存为书签了,这时应该按 Location 首部字段提示的 URI 从新保存。 像下方给出的请求 URI,当指定资源路径的最后忘记添加斜杠“/”,就 会产生 301 状态码。权限
临时性重定向。该状态码表示请求的资源已被分配了新的 URI,但愿 用户(本次)能使用新的 URI 访问。 和 301 Moved Permanently 状态码类似,但 302 状态码表明的资源不 是被永久移动,只是临时性质的。换句话说,已移动的资源对应的 URI 未来还有可能发生改变。好比,用户把 URI 保存成书签,但不会 像 301 状态码出现时那样去更新书签,而是仍旧保留返回 302 状态码 的页面对应的 URI。
该状态码表示因为请求对应的资源存在着另外一个 URI,应使用 GET 方法定向获取请求的资源。
当 30一、30二、303 响应状态码返回时,几乎全部的浏览器都会把 POST 改为 GET,并删除请求报文内的主体,以后请求会自动再次 发送。 30一、302 标准是禁止将 POST 方法改变成 GET 方法的,但实际使 用时你们都会这么作。
该状态码表示客户端发送附带条件的请求 2 时,服务器端容许请求访 问资源,但未知足条件的状况。304 状态码返回时,不包含任何响应 的主体部分。304 虽然被划分在 3XX 类别中,可是和重定向没有关 系。 附带条件的请求是指采用 GET 方法的请求报文中包含 If-Match,If-ModifiedSince,If-None-Match,If-Range,If-Unmodified-Since 中任一首部。
临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET,但实际使用时你们并不遵照。 307 会遵守浏览器标准,不会从 POST 变成 GET。可是,对于处理响 应时的行为,每种浏览器有可能出现不一样的状况。
该状态码表示请求报文中存在语法错误。当错误发生时,需修改请求 的内容后再次发送请求。另外,浏览器会像 200 OK 同样对待该状态 码。
该状态码表示发送的请求须要有经过 HTTP 认证(BASIC 认证、 DIGEST 认证)的认证信息。另外若以前已进行过 1 次请求,则表示 用 户认证失败。 返回含有 401 的响应必须包含一个适用于被请求资源的 WWWAuthenticate 首部用以质询(challenge)用户信息。当浏览器初次接收 到 401 响应,会弹出认证用的对话窗口。
该状态码代表对请求资源的访问被服务器拒绝了。服务器端没有必要 给出拒绝的详细理由,但若是想做说明的话,能够在实体的主体部分对缘由进行描述,这样就能让用户看到了。 未得到文件系统的访问受权,访问权限出现某些问题(从未受权的发 送源 IP 地址试图访问)等列举的状况均可能是发生 403 的缘由。
该状态码代表服务器上没法找到请求的资源。除此以外,也能够在服 务器端拒绝请求且不想说明理由时使用。
该状态码代表服务器端在执行请求时发生了错误。也有多是 Web 应用存在的 bug 或某些临时的故障。
该状态码代表服务器暂时处于超负载或正在进行停机维护,如今没法 处理请求。若是事先得知解除以上情况须要的时间,最好写入 RetryAfter 首部字段再返回给客户端。
状态码和情况的不一致 很多返回的状态码响应都是错误的,可是用户可能察觉不到这点。 好比 Web 应用程序内部发生错误,状态码依然返回 200 OK,这种 状况也常常遇到。