12 | 响应状态码该怎么用？

1、4xx一般是服务端业务状态码，看业务上怎么解决的，5xx就比较多了，500、502比如是在lnmp架构下，500是php代码写的很烂，导致nginx的upstream接受错误，抛异常了。502就是php-fpm挂了。504说明有慢查询php-fpm可能还在运行着，可是ngx由于本身的超时设置已经主动断开了，entity too large就是上传发文件超过ngx本身设置，其它的好像还没遇到过，404大多是浏览器请求facon.ico导致的，现在前后端分离根本没这个东西 2、参数错误一般是通过接口返回具体的业务代码来表明，http响应报文一般都是200，也有400的，但是我的经验中一般是返回的body为json格式，然后里面通过一个errno来标识一下，具体怎么规定我觉得在接口文档中写清楚就好

个人对状态码使用的理解： 就目前项目开发的过程中，状态码的使用对业务程序来说，基本上很少去利用，大致都是nginx、tomcat、spring等这些框架、中间件会返回一些状态码，例如接口不存在，框架会返回404，nginx配置有问题或者拒绝访问返回403或者502等状态码，一旦正确进入业务接口的时候，不管请求的用户id是否在用户库中存在、以及请求参数中是否缺少必要参数，都是返回200状态码，只是在body的json里面会返回自己特有的业务错误码，例如: {"code":-1,"message:"userid参数必须填写"}。 整体来讲，开发业务的程序员很少会去思考该返回什么http状态码，不知道这样的开发过程是否标准？

课后题： 1、给个错误页面、或者弹窗报个错误，然后做跳转 2、在返回body里面写明错误原因，状态码一般给500 总结： 1、状态行结构： version【SP】status code【SP】reason【CRLF】 version：是HTTP协议的版本号，用处不大 reason：是原因短语，简短的文字描述，如果“OK”“Not Found”等等，也可以自定义，用处也不大，很多客户端会忽略，为了兼容早期的文本客户端 status code：状态码，不是错误码，表达状态。以代码的形式表示服务器对请求的处理结果。 2、状态码 RFC标准规定状态码是三位数，把状态码分成了五类，用数字的第一位表示分类。 * 1xx:提示信息，表示目前是协议处理的中间状态，还需要后续的操作; * 2xx: 成功，报文已经收到并被正确处理; * 3xx:重定向，资源位置发生变动，需要客户端重新发送请求; * 4xx:客户端错误，请求报文有误，服务器无法处理; * 5xx:服务器错误，服务器在处理请求时内部发生了错误。

第一个问题: 目前客户端基本都是解析成失败的情况，大部分给个失败错误友好界面 第二个问题: 目前服务器很多也是返回4xx的错误妈，感觉被烂用了，应该要返回5xx，然后我们还会定义一个msg字段，用来说明具体失败的原因

希望老师在后续的过程中讲一下206这个断点续传，是不是类似于百度网盘那种下载软件暂停后再继续下载也是类似的原理？

1.一般接口报错的话返回的body中都会封装有错误消息，显示消息即可，401一般都不作处理，比如获取登录用户的信息的接口，未登录的时候调是401，是因为没有带相应token过去，登录之后就能正常返回登录用户的信息了，自己处理的情况比如SPA，用户访问了一个不存在的路由，此时前端自己返回一个404的页面，里面是一张图片：“么么哒，网页找不到了耶”之类的🤣🤣，5xx这个时候需要找服务端沟通了，正式上线一般不会出现5xx的错误，一般在开发时出现 2.返回的body中告知前端错误信息 另外就是老师貌似忘了讲401了，401也挺常见/用的，默认原因短语是"Unauthorized"，比如调登录接口没带授权的时候

作业 1.跳自定义错误页面 2.返回json，用code字段表示具体业务错误代码比如：100001，msg字段表示错误原因比如：缺少id，状态响应码还是200

看了评论后，有点困惑……对于第二个问题，我觉得是很明显的客户端错误，应该很自然的用400 bad request 然后用body 拓展详细的错误。 为什么好像200 ok很流行呢？是历史遗留问题么？ 很多框架包装了一个方法，类似于，issucesscode, ensuresucesscode ……，如果有这样不符合约定的状态码用法，你自己用，当然怎么都可以，要是开放给别的用户，应该会有很多问题吧。 比如，别人有一套框架，5xx直接显示一个通用错误消息，400才从body读具体消息，结果，你把validation error 放到5xx，那你的客户还得专门为你写一套处理方法。

作业： 1、统一跳转到一个报错页面 2、自定义一个4XX代码，告知客户端缺少了一个query。 状态码 目前的RFC标准里规定状态码是三位数，取值范围从100~599，用数字第一位表示分类，共五类，这五类具体含义是： · 1XX ：提示信息，表示目前是协议处理的中间状态，還需要后续的操作； · 2XX ：成功，报文已经收到并被正确处理； · 3XX ：重定向，资源位置发生变动，需要客户端重新发送请求； · 4XX ：客户端错误，请求报文有误，服务器无法处理； · 5XX ：服务器错误，服务器在处理请求时内部发生了错误。 1xx 此类属于提示信息，是协议处理的中间状态，实际能够用到的时候很少。 101 Swiching Protocols 意思是客户端使用Upgrade头字段，要求在HTTP协议基础上改成其他协议继续通信，比如WebSocket，如果服务器统一变更协议，就会返回101，后续数据传输就不会再使用HTTP了。 2xx 此类表示服务器收到并成功处理了客户端的请求，客户端最喜欢的状态码。 200 ok 浏览器最喜欢的成功了； 202 Accepted 浏览器收到请求，但暂缓处理，暂时无法给出处理结果； 204 No Content 含义与200 OK基本相同，但响应头后没有body数据； 206 Particl Content 意思是服务器成功处理了请求，但body里的数据不是资源的全部，而是一部分，这个是HTTP分块下载或断点续传的基础，在客户端放松了“范围请求”、要求获取资源的部分数据时出现。一般206后会跟着头字段“Content-Range”，表示body里数据的具体范围，例如“Content-Range：bytes 0-99/2000”。 3xx 此类表示客户端请求的资源发生了改动，客户端必须用新的URI创新发送请求获取资源，也就是通常所说的”重定向“，包括注明的301、302跳转。 301 Moved Permanently 俗称“永久重定向”，含义是此次请求的资源已经不存在了，需要该用新的URI再次访问。 302 Found 俗称“临时重定向”，意思是请求的资源还在，但需要暂时用了一个URI来访问。 304 Not Modified 即“缓存重定向”，用于If-Modified-Since等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义。 4xx 此类表示客户端发送的请求报文有无，服务器无法处理，含义就是“错误码”。 400 Bad Request 含义就是数据格式有误，具体哪里错误没有明说，会让客户端一头雾水，开发WEB应用时应该尽量避免； 403 Forbidden 这个不是客户的的请求出错，而是服务器禁止访问资源。愿意多种多样，可能是信息敏感、法律禁止等； 404 Not Found 被滥用的状态码，愿意是请求的资源在服务器上找不到，但很多服务器动不动就给你来个404； 405 Method Not Allowed 不允许使用某些方法操作资源，例如不允许POST只允许GET; 406 Not Acceptable 资源无法满足客户端请求的条件，例如请求中文但只有英文； 408 Request Timeout 请求超时，服务器等待了过长的时间； 409 Conflict 多个请求发生了冲突，可以理解为多线程并发时的竞争状态； 413 Request Enitity Too Large 请求报文里的body太大； 414 Request-URI Too Long 请求行里的URI太长； 429 Too Many Requests 客户端发送了太多请求，通常是由于服务器的限制连接策略； 431 Request Header Fields Too Large 请求头某个字段或总体太大。 5xx 此类表示客户端请求报文正确，但服务器在处理时内部发生了错误，无法返回应有的响应数据，是服务器端的“错误码”。 500 Internal Server Error 相当于服务器端的400,属于通用错误码，不利于调试，但能够防止黑客窥探或分析； 501 Not Implemented 表示客户端请求的功能还不支持； 502 Bad Gateway 通常是服务器作为王冠或者代理是返回的错误码，表示服务器自身工作正常，访问后端服务器时发生错误，具体错误原因未知； 503 Service Unavailable 服务器繁忙，当前不可用，这是一个临时的状态，通常503的响应报文里会有一个“Retry-After”字段，意思是多久后再重试。

【课后思考题】 1. 你在开发 HTTP 客户端，收到了一个非标准的状态码，比如 4××、5××，应当如何应对呢？ 我个人感觉4XX和5XX还是要区分开提示。4XX主要是客户端错误，5XX主要是服务端处理错误。如果是我开发客户端遇到这个问题，我会和业务人员沟通要如何进行客户提示，如：4XX一律提示为“请求有误，请稍后再试” 5XX一律提示为“服务器繁忙，请稍后重试”； 2. 你在开发 HTTP 服务器，处理请求时发现报文里缺了一个必需的 query 参数，应该如何告知客户端错误原因呢？ 返回4xx错误，并在返回json报文中定义详细错误代号，如：{code: "-1"; msg:QUERY_ERROR; ......}