可能是最详细的HTTP状态码介绍 常见状态码包含实际应用场景及解决办法
HTTP 状态码负责表示客户端 HTTP 请求的返回结果、 标记服务器端
的处理是否正常、 通知出现的错误等工作。
状态码导航
- 2XX 成功
- 200 OK
- 204 No Content
- 206 Partial Content
- 3XX重定向
- 301 Moved Permanently
- 302Found
- 301、302的选择
- 303 See Other
- 307 Temporary Redirect
- 302，302，307区别
- 304 Not Modiified
- 4XX客户端错误
- 400 Bad Request
- 401 Unauthorized
- 解决401错误
- 403 Forbidden
- 403解决办法
- 404 Not Found
- 5XX服务器错误
- 500 Internal Server Error
- 503 Service Unavaliable
- 1XX 请求处理中
2XX 成功
200 OK
表示从客户端发来的请求在服务端被正常处理了。
204 No Content
服务器接收到的请求已成功处理，但在返回的响应报文中不含实体的主体部分。一般在只需从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
206 Partial Content
表示客户端进行了 范围请求，而服务端成功执行了这部分的get请求。
这种请求可用于：
- 学习http头和状态.
- 解决网路问题.
- 解决大文件下载问题.
- 解决CDN和原始HTTP服务器问题.
- 使用工具例如lftp,wget,telnet测试断电续传.
- 测试将一个大文件分割成多个部分同时下载.
判断服务端是否支持该种请求可以通过head请求去尝试，关注服务端返回的相应中的请求头的以下字段。
Accept-Ranges: bytes - 该响应头表明服务器支持Range请求,以及服务器所支持的单位是字节(这也是唯一可用的单位).我们还能知道:服务器支持断点续传,以及支持同时下载文件的多个部分,也就是说下载工具可以利用范围请求加速下载该文件 .Accept-Ranges: none 响应头表示服务器不支持范围请求.
Content-Length: 36907 - Content-Length响应头表明了响应实体的大小
Range请求头辨认出一个部分内容请求.该请求头表明了客户端需要请求资源的哪一部分:
在上图的请求中,客户端告诉服务器,它需要该视屏文件中从172,032到13,325,503字节范围内的数据.。
在大多数情况下,客户端还会发送一些条件请求头,让服务器来辨别该返回哪个版本的资源.在上图的请求中,客户端把它在上次接收该资源的0到172032字节部分请求中服务器返回的ETag响应头作为了本次请求的If-Match请求头发送了出去,同样还把上次响应中的Last-Modified响应头用If-Unmodified-Since请求头发送了出去.
如果服务器发现该资源的版本与客户端所请求的版本不匹配,则会返回一个HTTP/412 Precondition Failed响应.如果客户端使用If-Range请求头而不是If-Match发送了上次收到的ETag响应头的值,且服务器发现客户端请求的版本与当前资源的版本不匹配,则服务器会返回整个资源数据.如果客户端需要完整的资源数据,使用If-Range可以减少一个网络请求. 服务器的Content-Range响应头表明了返回的是文件的哪一部分,Content-Length响应头表明了该部分文件的大小:
你也许注意到了Accept-Ranges响应头,服务器发送这个头的目的是让客户端知道服务器接受以字节为单位的部分内容请求.
如果你在Fiddler中看到了一个HTTP/206响应,但你需要的是一个完整的文件(比如你想保存一个完整的视屏文件),你可以选中该会话按下U键,或者按住Ctrl键点击工具栏中的Replay按钮,执行无条件请求
3XX重定向
3XX 相应结果表明浏览器需要执行某些特殊的处理以正确处理请求。
简单解释什么是重定向以及为什么要重定向？
重定向可以简单理解为跳转链接。
1）网站调整（如改变网页目录结构）；
2）网页被移到一个新地址；
3）网页扩展名改变(如应用需要把.php改成.Html或.shtml)。
这种情况下，如果不做重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也需要通过重定向让访问这些域名的用户自动跳转到主站点等。
301 Moved Permanently
永久性重定向。该状态码表示请求的资源已经被分配了新的url，以后应使用资源现在所指的 URI。 表示旧地址A的资源已经被永久地移除了（这个地址不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址。也就是说， 如果已经把资源对应的 URI保存为书签了， 这时应该按 Location 首部字段提示的 URI 重新保存。
使用301的场景：
1）域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
2）在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。
3）空间服务器不稳定，换空间的时候。
4）http升级https
302Found
临时性重定向。该状态码表示请求的资源已被分配了新的 URI， 希望用户（本次） 能使用新的 URI 访问。
比如未登陆的用户访问用户中心重定向到登录页面。访问404页面会重新定向到首页。
和 301 Moved Permanently 状态码相似， 但 302 状态码代表的资源不是被永久移动， 只是临时性质的。 换句话说， 已移动的资源对应的URI 将来还有可能发生改变。 比如， 用户把 URI 保存成书签， 但不会像 301 状态码出现时那样去更新书签， 而是仍旧保留返回 302 状态码的页面对应的 URI。
使用302的一些场景：
1)未登录的时候跳转到登陆页面
2)404的时候跳转到首页
301、302的选择
如果从便于搜索引擎友好的话当然是301最合适，一般情况下非特意临时性URL转移，都尽量用301跳转，这样的一个好处是搜索引擎会把该URL的PR值都带到跳转后的地址，而302跳转早期被很多网站当作作弊手段，已经被多数搜索引擎重点盯查。
而性能方面原则上301跳转和302跳转没有多大差别，不过考虑到搜索引擎个案对待，也建议使用301跳转，301跳转搜索引擎是不对原地址进行访问的，而302跳转除了可能被劫持之外，还有可能会加大对服务器的URL请求数量。
搜索引擎对302跳转进行判断的时候，如果发现跳转目标页面URL更加复杂，就会返回来对原URL进行访问，寻取一个简单友好的地址，这样无形会加重服务器性能损耗，因此301跳转要比302跳转靠普也对服务器性能有保障。301的含义是“永久重定向”，而302的含义是“临时重定向”。301代表永久性转移是网页更改地址后对搜索引擎友好的最好方法，只要不是暂时搬移的情况,都建议使用301来做转址。
从网址A 做一个302 重定向到网址B 时，主机服务器的隐含意思是网址A 随时有可能改主意，重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下，当收到302 重定向时，一般只要去抓取目标网址就可以了，也就是说网址B。如果搜索引擎在遇到302 转向时，百分之百的都抓取目标网址B 的话，就不用担心网址URL 劫持了。问题就在于，有的时候搜索引擎，尤其是Google，并不能总是抓取目标网址。比如，一个不道德的人在他自己的网址A 做一个302 重定向到你的网址B，出于某种原因（比如A网址的url很短，而b网址的url很长而且带很多参数不够美观）， Google 搜索结果所显示的仍然是网址A，但是所用的网页内容却是你的网址B 上的内容，这种情况就叫做网址URL 劫持。你辛辛苦苦所写的内容就这样被别人偷走了。302 重定向所造成的网址URL 劫持现象，已经存在一段时间了。
url劫持的理解大概是，从网站A（网站比较烂）上做了一个302跳转到网站B（搜索排名很靠前），这时候有时搜索引擎会使用网站B的内容，但却收录了网站A的地址，这样在不知不觉间，网站B在为网站A作贡献，网站A的排名就靠前了。
301跳转对查找引擎是一种对照驯良的跳转编制，也是查找引擎能够遭遇的跳转编制，它告诉查找引擎，这个地址弃用了，永远转向一个新地址，可以转移新域名的权重。而302重定向很容易被搜索引擎误认为是利用多个域名指向同一网站，那么你的网站就会被封掉，罪名是“利用重复的内容来干扰Google搜索结果的网站排名”。
303 See Other
该状态码表示请求存在着另一个url，应该使用GET方法获取请求的组员。
303 状态码和 302 Found 状态码有着相同的功能， 但 303 状态码明确
表示客户端应当采用 GET 方法获取资源， 这点与 302 状态码有区
别。
307 Temporary Redirect
临时重定向。该状态码与302Found有着 相同的含义。尽管302标准禁止POST变换成GET,但实际使用时大家并不遵守。
307会遵照浏览器标准，不会从POST变成GET。但是，对于处理响应时的行为，每种浏览器可能出现不同的情况。
302，302，307区别
303和307是HTTP1.1新加的服务器响应文档的状态码，它们是对HTTP1.0中的302状态码的细化，主要用在对非GET、HEAD方法的响应上。文档规定：浏览器对303状态码的处理跟原来浏览器对HTTP1.0的302状态码的处理方法一样；浏览器对307状态码处理则跟原来HTTP1.0文档里对302的描述一样。
303和307的存在，归根结底是由于POST方法的非幂等属性引起的。
在HTTP1.1中，302理论上是要被放弃掉的，它被细化为303和307，但为了兼容，它目前还在业界中大量使用，而303和307状态码我还没遇到过（没有使用场景，也没抓到过这样的响应报文）。为什么业界少使用303和307呢？对于GET和HEAD方法来说，307是没必要存在的，用302或者303就可以满足需求了，307仅在POST方法的重定向上有用处。所以我猜测它们少见的原因有两方面：1、POST方法重定向的使用场景太少，使得307状态码没有用武之地；2、GET方法虽然常需要使用的重定向，但使用302状态码也能正确运转，再考虑到微乎其微的兼容问题（现在的浏览器怎么可能不支持HTTP1.1呢！），也就没有使用303的必要了。
304 Not Modiified
该状态码表示客户端发送附带条件的请求 2 时， 服务器端允许请求访
问资源， 但未满足条件的情况。 304 状态码返回时， 不包含任何响应
的主体部分。 304 虽然被划分在 3XX 类别中， 但是和重定向没有关
系。
2 附带条件的请求是指采用 GET方法的请求报文中包含 If-Match， If-ModifiedSince， If-None-Match， If-Range， If-Unmodified-Since 中任一首部。
304状态码其实是客户端和服务端多确认了一次缓存的有效性后返回的 可用缓存信息的状态码。
涉及浏览器的强缓存与协商缓存：可以点击此处了解更多，此处不再赘述
关注一下协商缓存中的etag：etag是根据实体内容生成的一段hash字符串（类似于MD5或者SHA1之后的结果），可以标识资源的状态。 当资源发送改变时，ETag也随之发生变化。
为什么使用ETag呢？ 主要是为了解决Last-Modified 无法解决的一些问题。
-
某些服务器不能精确得到文件的最后修改时间， 这样就无法通过最后修改时间来判断文件是否更新了。
-
某些文件的修改非常频繁，在秒以下的时间内进行修改. Last-Modified只能精确到秒。
-
一些文件的最后修改时间改变了，但是内容并未改变。 我们不希望客户端认为这个文件修改了。
命中强缓存的时候，客户端不再去服务端请求（客户端与服务端不会通信），而是直接读取本地的缓存数据，状态码为200(from cache)，而未命中强缓存时则会向服务端请求，并判断是否命中协商缓存，如果命中则服务端返回304告诉客户端可以继续使用缓存（服务端只返回请求头，不返回主体）。
4XX客户端错误
4XX的相应结果表明客户端是发生错误的原因所在。
400 Bad Request
该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，状态码会像200一样对待该状态码。
出现这个请求无效报错说明请求没有进入到后台服务里，原因：
1）前端提交数据的字段名称或者是字段类型和后台的实体类不一致 或 前端提交的参数跟后台需要的参数个数不一致，导致无法封装；
2）前端提交的到后台的数据应该是json字符串类型，而前端没有将对象转化为字符串类型；
解决方案：
1）对照字段名称，类型保证一致性
2）使用stringify将前端传递的对象转化为字符串 data: JSON.stringify(param) ;
401 Unauthorized
该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证） 的认证信息。 另外若之前已进行过 1 次请求， 则表示用 户认证失败。
返回含有 401 的响应必须包含一个适用于被请求资源的 WWWAuthenticate 首部用以质询（challenge） 用户信息。 当浏览器初次接收到 401 响应， 会弹出认证用的对话窗口。
简单的来说: 就是你的Web服务器认为，客户端发送的 HTTP 数据流是正确的，但进入网址 (URL) 资源 ， 需要用户身份验证 ， 而相关信息 尚未被提供, 或 已提供但没有通过授权测试。
这就是通常所知的“ HTTP 基本验证 ，需客户端提供的验证请求在 HTTP 协议中被定义为 WWW – 验证标头字段 (WWW-Authenticate header field) 。
解决401错误
如果遇到401问题, 我们解决的思路,可以这样来考虑:
- 优先考虑是否是需要验证用户身份,也就是是否需要授权账号和密码信息;
- 如果是开放的服务器资源, 需要考虑的是是否有防御性的安全策略;
情景一: 需要提供密码和账号
当服务器需要验证您的帐户时，您可以有选择性地提供两项信息网站用户名,网站密码。
当然只有当您的站点使用 HTTP 基本验证时您才应该提供这些信息。 如果您不提供这些信息，服务器是通不过的,您也会得到 401 错误。
当在服务器端设定了需要验证时，这种情况下,我们就需要提供账号和密码给服务器了,当然,实际开发中,密码和账号是需要严格加密的,都是需要和服务器人员沟通一套非常保密的加密的方法的, 整个过程是比较复杂的,
情景二:有防御性的安全策略
如果你认为该网站上的网页 应该 是对任何互联网用户开放的， 那么 401 信息就表明了一个更深层问题。 首先，您可以通过一个浏览器检查您的网址。 该浏览器应该运行在一台您以前从未使用过， 也不包含任何有关您的信息的计算机上， 同时， 您还应避免使用您以前用过的身份验证（密码等）。 理想情况是， 这一切应该通过一个完全不同于任何您用过的互联网连接（例如由不同的互联网服务供应商- ISP 提供的拨号连接）。 简而言之，您要模拟一个完全陌生的人通过网上冲浪访问您的网页的情况。
比如: iOS9.0之后,就统一规定,对于http请求,只有经过苹果认可的证书且是https:// 的,才可以直接通过访问,如果还是http:// 或者,不是苹果认可的证书的https,都是不可以直接访问的, 所以,通常情况下,解决这类问题,我们会事先在info.plist文件中做一些配置, 也就是我们常说的ATS配置。
点击查看更详细的解决方案
403 Forbidden
该状态码表明对请求资源的访问被服务器拒绝了。 服务器端没有必要给出拒绝的详细理由， 但如果想作说明的话， 可以在实体的主体部分对原因进行描述， 这样就能让用户看到了。
导致403错误的主要原因
未获得文件系统的访问授权， 访问权限出现某些问题（从未授权的发送源 IP 地址试图访问） 等列举的情况都可能是发生 403 的原因。
1、你的IP被列入黑名单。
2、你在一定时间内过多地访问此网站（一般是用采集程序），被防火墙拒绝访问了。
3、网站域名解析到了空间，但空间未绑定此域名。
4、你的网页脚本文件在当前目录下没有执行权限。
5、在不允许写/创建文件的目录中执行了创建/写文件操作。
6、以http方式访问需要ssl连接的网址。
7、浏览器不支持SSL 128时访问SSL 128的连接。
8、在身份验证的过程中输入了错误的密码。
9、DNS解析错误，手动更改DNS服务器地址。
10、连接的用户过多，可以过后再试。
11、服务器繁忙，同一IP地址发送请求过多，遭到服务器智能屏蔽。
403解决办法
①清除重建dns缓存：常规的403 Forbidden错误，我们可以尝试先清除dns缓存，然后再重建dns缓存。具体方法就是：在运行中输入cmd，然后输入ipconfig/flushdns即可。如果不行，就需要在hosts文件里把主页解析下了。
②设置网站默认主页：403 Forbidden错误的出现，有时候，也可能因为网站默认主页设置不当，从而木有访问权限的原因。网站新建般默认文档为：index.html；index.asp；index.php；index.jsp；default.htm；default.asp等，如果我们的页文件名不是默认文档种的种，我们就需要在网站虚拟目录中添加默认文档，如下图所示：
③修改文件夹安全属性：由于网站某文件夹属性设置不当，会使netuser没有网站访问权限，从而导致403 Forbidden错误的出现，我们只需要修改文件夹安全属性，给予网络普通用户访问权限即可。如下图：
④关于apache导致的403 forbidden错误的解决办法
打开apache的配置文件httpd.conf，找到这段代码：
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
有时候由于配置了php后，这里的“Deny from all”已经拒绝了一切连接。把该行改成“allow from all”，修改后的代码如下，问题解决。
Options FollowSymLinks
AllowOverride None
Order deny,allow
Allow from all
之所以会出现错误，是因为大多数的国外主机在配置Apache的时候启用了mod_security，也就是开启了安全检查，如果提交的信息中包含select , % , bin等关键字，Apache就会禁止，并给出403，404，500等错误。
4、关于HawkHost空间出现403 Forbidden错误的解决方法
有的时候在共享服务器上安装了Mod security，当网址包含有“%”号等其它敏感字符时，就会被Mod security阻止，马海祥博客曾经也出现过此情况。
解决HawkHost 403 Forbidden 错误的方法：
在.htaccess文件里添加如下代码：
SecFilterEngine Off
SecFilterScanPOST Off
直接放在网站的根目录或者程序运行的目录下。
5、关于WordPress导致的403 Forbidden错误解决方法
对于一些使用WordPress管理程序搭建的博客来说，就需要修改.htaccess文件，在后面添加上如下内容即可，其实就是disable mod_security
SecFilterEngine Off
SecFilterScanPOST Off
另外dedecms的可能还需要再加一条，以让默认访问的是index.html文件的DirectoryIndex index.html。修改.htaccess文件，将文件上传之后，再重新打开之前出现403 Forbidden的URL就没有再出现错误，直接可以打开了。
除了个人使用vps、服务器以及国外些主机等建站的时候，403 Forbidden错误的出现，可能会和服务器本身权限设置错误有关，大多情况下，些免费的建站软件，比如WordPress、DEDECMS等的设置不当，也会导致403 Forbidden错误的出现，我们可以根据建站环境寻找对应的解决403 Forbidden错误的方法。
点此了解更多
404 Not Found
该状态码表明服务器上无法找到请求的资源。 除此之外， 也可以在服
务器端拒绝请求且不想说明理由时使用。
404错误经常是由于请求的url地址错误导致的。
PS：404错误页面要返回“202”或“302”状态码吗？
从严格的技术角度，网站对404错误的处理策略，并不是一个SEO方面的工作，而属于网站可用性(usability)方面的问题。——当然，如果从广义的SEO范畴来看，提高网站可用性也属于SEO的基本操作。——但是，如果自定义404错误页面设置不当，则会极大地影响网站的SEO效果。
在许多朋友的印象中，自定义404错误页面只要能正确显示，只要能输入网站内某个并不存在的网页地址，在浏览器中能看到自定义的错误信息，便说明设置没问题。一个正确设置的404页面，不仅应当正确地显示，同时，应该能够正确返回“404”错误代码，而不是“200”或“302”。虽然对访问的用户而言，HTTP状态码究竟是“404”还是“200”来说并没有什么区别，但对搜索引擎而言，这则是相当重要的。
为什么这么说呢？让我们先来回顾一下搜索引擎收录与索引网页的过程：搜索引擎的Spider向网站服务器发送请求，要求读取某个网页，网站服务器接到请求后返回HTTP状态码响应请求，这些返回的HTTP状态码决定着搜索引擎的下一步行动：将该网页收录到索引数据库或者将其从索引数据库删除等。
当然，HTTP状态码有很多种，分别对应不同的情况，下面就与本文内容相关的几种作一简单介绍，更详细的信息可参考W3C规范：
404:请求的网页不存在(不排除日后该链接有效的可能性)；
410:请求的网页不存在(永久)；
200:服务器成功返回网页
302:网址临时重定向(跳转
301:网址永久重定向
需要说明的是，大部分搜索引擎将“404”与“410”状态同等对待，如Google。(参见MattCutts的说明
当搜索引擎在请求某个Url时得到“404”状态回应时，便会知道该网页在网站内不复存在，从而在索引数据库中将其删除，——当然，这个删除过程有可能需要很长时间——而当搜索引擎得到“200”状态回应时，则会认为该url是有效的，并将其回到到索引数据库中。
详情请点击
5XX服务器错误
500 Internal Server Error
该状态码表明服务端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。
点此了解更多
503 Service Unavaliable
该状态码表明服务器暂时处于超负载或正在进行停机维护， 现在无法
处理请求。 如果事先得知解除以上状况需要的时间， 最好写入
RetryAfter 首部字段再返回给客户端。
1XX 请求处理中
信息状态码，表示接收的请求正在被处理。
参考：
《图解Http》
http://www.cnblogs.com/cswuyg/p/3871976.html
https://www.cnblogs.com/dingzhaoming/p/8628507.html
https://www.jianshu.com/p/ca3e561e09ae
https://www.cnblogs.com/jiaoaozuoziji/p/7283322.html