HTTP状态码超详细说明

前言
这里是我整理的HTTP状态码对照表,有常用的,也有不常用的 , 需要的同学可以对应查询看看 。
分类
HTTP状态码由三个十进制数字组成 , 其中第一个十进制数字定义了状态码的类型 。
HTTP状态码共分为5种类型:
分类
分类描述
1**
信息 , 服务器收到请求 , 需要请求者继续执行操作
2**
成功,操作被成功接收并处理
3**
重定向,需要进一步的操作以完成请求
4**
客户端错误,请求包含语法错误或无法完成请求
5**
服务器错误,服务器在处理请求的过程中发生了错误
下面我将分系列给大家详细介绍 。
1xx系列
100Continue继续 。客户端应继续其请求
客户端应当继续发送请求 。
这个临时响应是用来通知客户端它的部分请求已经被服务器接收 , 且仍未被拒绝 。
客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应 。服务器必须在请求完成后向客户端发送一个最终响应 。
101Switching Protocols切换协议 。服务器根据客户端的请求切换协议 。只能切换到更高级的协议,例如,切换到HTTP的新版本协议
服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求 。
在发送完这个响应最后的空行后,服务器将会切换到在Upgrade 消息头中定义的那些协议 。只有在切换新的协议更有好处的时候才应该采取类似措施 。
例如,切换到新的HTTP 版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源 。
102处理将被继续执行 。
由WebDAV应重置文档视图 。可通过此返回码清除浏览器的表单域
服务器成功处理了请求,且没有返回任何内容 。
但是与204响应不同,返回此状态码的响应要求请求者重置文档视图 。
该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入 。
与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束 。
206Partial Content部分内容 。服务器成功处理了部分GET请求
服务器已经成功处理了部分 GET 请求 。
类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载 。
该请求必须包含 Range 头信息来指示客户端希望得到的内容范围,并且可能包含 If-Range 来作为请求条件 。
响应必须包含如下的头部域:
Content-Range 用以指示本次响应中返回的内容的范围;如果是 Content-Type 为 multipart/byteranges 的多段下载,则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围 。
假如响应中包含 Content-Length , 那么它的数值必须匹配它返回的内容范围的真实字节数 。DateETag 和/或 Content-Location,假如同样的请求本应该返回200响应 。
Expires, Cache-Control,和/或 Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话 。
假如本响应请求使用了 If-Range 强缓存验证,那么本次响应不应该包含其他实体头;
假如本响应的请求使用了 If-Range 弱缓存验证 , 那么本次响应禁止包含其他实体头;这避免了缓存的实体内容和更新了的实体头信息之间的不一致 。否则,本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域 。
假如 ETag 或 Last-Modified 头部不能精确匹配的话,则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起 。
任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容 。
207之后的消息体将是一个XML消息 , 并且可能依照之前子请求数量的不同
由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码 。
3xx系列
300Multiple Choices多种选择 。请求的资源可包括多个位置 , 相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息 。
用户或浏览器能够自行选择一个首选的地址进行重定向 。
除非这是一个 HEAD 请求 , 否则该响应应当包括一个资源特性及地址的列表的实体 , 以便用户或浏览器从中选择最合适的重定向地址 。
这个实体的格式由 Content-Type 定义的格式所决定 。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择 。
当然 , RFC 2616规范并没有规定这样的自动选择该如何进行 。
如果服务器本身已经有了首选的回馈选择,那么在 Location 中应当指明这个回馈的 URI;浏览器可能会将这个 Location 值作为自动重定向的地址 。此外,除非额外指定 , 否则这个响应也是可缓存的 。
301Moved Permanently永久移动 。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI 。今后任何新的请求都应使用新的URI代替
被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一 。
如果可能,拥有链接
新的永久性的 URI 应当在响应的 Location 域中返回 。
除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明 。
如果这不是一个 GET 或者 HEAD 请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化 。
注意:对于某些使用 HTTP/1.0 协议的浏览器,当它们发送的 POST 请求得到了一个301响应的话 , 接下来的重定向请求将会变成 GET 方式 。
302Found临时移动 。与301类似 。但资源只是临时被移动 。客户端应继续使用原有URI
请求的资源现在临时从不同的 URI 响应请求 。
由于这样的重定向是临时的,客户端应当继续向原有地址发送
【HTTP状态码超详细说明】以上就是朝夕生活(www.30zx.com)关于“HTTP状态码超详细说明”的详细内容,希望对大家有所帮助!

猜你喜欢