HTTP协议图--HTTP 响应状态码(重点分析)

  1. 状态码概述

    HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。

    HTTP 状态码如 200 OK ,以 3 位数字和原因短语组成。数字中的第一位指定了响应类别,后两位无分类。

    不少返回的响应状态码都是错误的,但是用户可能察觉不到这点。比如 Web 应用程序内部发生错误,状态码依然返回 200 OK。

  2. 状态码类别

    类别 原因短语

    1xx Informational(信息性状态码) 接收的请求正在处理

    2xx Success(成功状态码) 请求正常处理完毕

    3xx Redirection(重定向状态码) 需要进行附加操作以完成请求

    4xx Client Error(客户端错误状态码) 服务器无法处理请求

    5xx Server Error(服务器错误状态码) 服务器处理请求出错

    我们可以自行改变 RFC2616 中定义的状态码或者服务器端自行创建状态码,只要遵守状态码的类别定义就可以了。

  3. 常用状态码解析

    HTTP 状态码种类繁多,数量达几十种。其中最常用的有以下 14 种,一起来看看。

3.1 200 OK

表示从客户端发来的请求在服务器端被正常处理了。

3.2 204 No Content

代表服务器接收的请求已成功处理,但在返回的响应报文中不含实体的主体部分。另外,也不允许返回任何实体的主体。

一般在只需要从客户端向服务器端发送消息,而服务器端不需要向客户端发送新消息内容的情况下使用。

3.3 206 Partial Content

表示客户端进行了范围请求,而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 首部字段指定范围的实体内容。

3.4 301 Moved Permanently

永久性重定向。表示请求的资源已被分配了新的 URI。以后应使用资源现在所指的 URI。也就是说,如果已经把资源对应的 URI 保存为书签了,这时应该按 Location 首部字段提示的 URI 重新保存。

3.5 302 Found

临时性重定向。表示请求的资源已被分配了新的 URI,希望用户(本次)能使用新的 URI 访问。

和 301 Moved Permanently 状态码相似,但 302 Found 状态码代表资源不是被永久移动,只是临时性质的。换句话说,已移动的资源对应的 URI 将来还有可能发生改变。

3.6 303 See Other

表示由于请求的资源存在着另一个 URI,应使用 GET 方法定向获取请求的资源。

303 See Other 和 302 Found 状态码有着相同的功能,但 303 See Other 状态码明确表示客户端应采用 GET 方法获取资源,这点与 302 Found 状态码有区别。

3.7 304 Not Modified

表示客户端发送附带条件的请求时,服务器端允许请求访问的资源,但未满足条件的情况。

304 Not Modified 状态码返回时,不包含任何响应的主体部分。

304 Not Modified 虽然被划分到 3xx 类别中,但和重定向没有关系。

3.8 307 Temporary Redirect

临时重定向。该状态码与 302 Found 有着相同的含义。

3.9 400 Bad Request

表示请求报文中存在语法错误。当错误发生时,需修改请求的内容后再次发送请求。

另外,浏览器会像 200 OK 一样对待该状态码。

3.10 401 Unauthorized

表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。

另外,若之前已进行过 1 次请求,则表示用户认证失败。

返回含有 401 Unauthorized 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。

3.11 403 Forbidden

表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出详细的拒绝理由,当然也可以在响应报文的实体主体部分对原因进行描述。

3.12 404 Not Found

表明服务器上无法找到请求的资源。除此之外,也可以在服务器端拒绝请求且不想说明理由的时候使用。

3.13 500 Internal Server Error

表明服务器端在执行请求时发生了错误。也可能是 Web 应用存在的 bug 或某些临时的故障。

3.14 503 Service Unavailable

表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。如果事先得知解除以上状况需要的时间,最好写入 Retry-After 首部字段再返回给客户端。

相关推荐
风落无尘5 小时前
《智能重生:从垃圾堆到AI工程师》——第五章 代码与灵魂
服务器·网络·人工智能
S1998_1997111609•X7 小时前
论当今社会主义与人文关怀人格思想下的恶意仿生注入污染蜜罐描述进行函数值非法侵入爬虫的咼忄乂癿〇仺⺋.
数据库·网络协议·百度·ssh·开闭原则
其实防守也摸鱼8 小时前
CTF密码学综合教学指南--第九章
开发语言·网络·python·安全·网络安全·密码学·ctf
xlq223229 小时前
50.UDP套接字
网络·网络协议·udp
南境十里·墨染春水9 小时前
linux学习笔记 网络编程——Socket入门与TCP客户端/服务器实现
linux·服务器·网络
qq_三哥啊9 小时前
【mitmproxy】通过 mitmproxy 的HTTP代理模式获取 OpenCode 发起的 AI API 请求的详细信息
网络·http·代理模式
nikolay10 小时前
AI重塑企业信息安全:攻防升级与信任重构
网络·人工智能·网络安全
Yupureki10 小时前
《Linux网络编程》6.UDP原理
linux·运维·服务器·网络·udp
wapicn9911 小时前
设置好这一步,让你的SSL证书在到期前自动续期,永不过期
网络·网络协议·ssl
Harvy_没救了12 小时前
【网络运维】 WordPress 部署复盘
运维·网络