接口请求返回状态码总结

前端在调用接口时都要关注接口返回给我们的状态码,之前只是大概的了解比如404是前端的错,可能是路径错误等,300+可能是重定向了,500以上是服务端或者服务器的错误,并没有一个很好的总结。今天中午看群里有人问这问题,就搜集对比整理了一下,如下:

1xx - 信息提示

这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个 1xx 响应。
· 100 - Continue 初始的请求已经接受,客户应当继续发送请求的其余部分。(HTTP 1.1新)
· 101 - Switching Protocols 服务器将遵从客户的请求转换到另外一种协议(HTTP 1.1新)

2xx - 成功

这类状态代码表明服务器成功地接受了客户端请求。
· 200 - OK 一切正常,对GET和POST请求的应答文档跟在后面。
· 201 - Created 服务器已经创建了文档,Location头给出了它的URL。
· 202 - Accepted 已经接受请求,但处理尚未完成。
· 203 - Non-Authoritative Information 文档已经正常地返回,但一些应答头可能不正确,因为使用的是文档的拷贝,非权威性信息(HTTP 1.1新)。
· 204 - No Content 没有新文档,浏览器应该继续显示原来的文档。如果用户定期地刷新页面,而Servlet可以确定用户文档足够新,这个状态代码是很有用的。
· 205 - Reset Content 没有新的内容,但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容(HTTP 1.1新)。
· 206 - Partial Content 客户发送了一个带有Range头的GET请求,服务器完成了它(HTTP 1.1新)。

3xx - 重定向

客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。
· 300 - Multiple Choices 客户请求的文档可以在多个位置找到,这些位置已经在返回的文档内列出。如果服务器要提出优先选择,则应该在Location应答头指明。
· 301 - Moved Permanently 客户请求的文档在其他地方,新的URL在Location头中给出,浏览器应该自动地访问新的URL。
· 302 - Found 类似于301,但新的URL应该被视为临时性的替代,而不是永久性的。注意,在HTTP1.0中对应的状态信息是“Moved Temporatily”。出现该状态代码时,浏览器能够自动访问新的URL,因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使用。例如,如果浏览器错误地请求 http://host/~user (缺少了后面的斜杠),有的服务器返回301,有的则返回302。严格地说,我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见 307。
· 303 - See Other 类似于301/302,不同之处在于,如果原来的请求是POST,Location头指定的重定向目标文档应该通过GET提取(HTTP 1.1新)。
· 304 - Not Modified 客户端有缓冲的文档并发出了一个条件性的请求(一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档)。服务器告诉客户,原来缓冲的文档还可以继续使用。
· 305 - Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取(HTTP 1.1新)。
· 307 - Temporary Redirect 和302(Found)相同。许多浏览器会错误地响应302应答进行重定向,即使原来的请求是POST,即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因,HTTP 1.1新增了307,以便更加清除地区分几个状态代码:当出现303应答时,浏览器可以跟随重定向的GET和POST请求;如果是307应答,则浏览器只能跟随对GET请求的重定向。(HTTP 1.1新)

4xx - 客户端错误


发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。

· 400 - Bad Request 请求出现语法错误。

400的返回body里面经常有Invalid argument provided (提供无效的参数)表明header或parameter里面有无效的参数。

· 401 - Unauthorized 访问被拒绝,客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头,浏览器据此显示用户名字/密码对话框,然后在填写合适的Authorization头后再次发出请求。IIS 定义了许多不同的 401 错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在 IIS 日志中显示:
· 401.1 - 登录失败。
· 401.2 - 服务器配置导致登录失败。
· 401.3 - 由于 ACL 对资源的限制而未获得授权。
· 401.4 - 筛选器授权失败。
· 401.5 - ISAPI/CGI 应用程序授权失败。
· 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

· 403 - Forbidden 资源不可用。服务器理解客户的请求,但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。禁止访问:IIS 定义了许多不同的 403 错误,它们指明更为具体的错误原因:
· 403.1 - 执行访问被禁止。
· 403.2 - 读访问被禁止。
· 403.3 - 写访问被禁止。
· 403.4 - 要求 SSL。
· 403.5 - 要求 SSL 128。
· 403.6 - IP 地址被拒绝。
· 403.7 - 要求客户端证书。
· 403.8 - 站点访问被拒绝。
· 403.9 - 用户数过多。
· 403.10 - 配置无效。
· 403.11 - 密码更改。
· 403.12 - 拒绝访问映射表。
· 403.13 - 客户端证书被吊销。
· 403.14 - 拒绝目录列表。
· 403.15 - 超出客户端访问许可。
· 403.16 - 客户端证书不受信任或无效。
· 403.17 - 客户端证书已过期或尚未生效。
· 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
· 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
· 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

· 404 - Not Found 无法找到指定位置的资源。这也是一个常用的应答。

404返回的body里面经常有description  :The requested resource () is not available.很有可能是url出了问题


· 404.0 -(无) – 没有找到文件或目录。
· 404.1 - 无法在所请求的端口上访问 Web 站点。
· 404.2 - Web 服务扩展锁定策略阻止本请求。
· 404.3 - MIME 映射策略阻止本请求。

· 405 - Method Not Allowed 请求方法(GET、POST、HEAD、Delete、PUT、TRACE等)对指定的资源不适用,用来访问本页面的 HTTP 谓词不被允许(方法不被允许)(HTTP 1.1新)
· 406 - Not Acceptable 指定的资源已经找到,但它的MIME类型和客户在Accpet头中所指定的不兼容,客户端浏览器不接受所请求页面的 MIME 类型(HTTP 1.1新)。
· 407 - Proxy Authentication Required 要求进行代理身份验证,类似于401,表示客户必须先经过代理服务器的授权。(HTTP 1.1新)
· 408 - Request Timeout 在服务器许可的等待时间内,客户一直没有发出任何请求。客户可以在以后重复同一请求。(HTTP 1.1新)
· 409 - Conflict 通常和PUT请求有关。由于请求和资源的当前状态相冲突,因此请求不能成功。(HTTP 1.1新)
· 410 - Gone 所请求的文档已经不再可用,而且服务器不知道应该重定向到哪一个地址。它和404的不同在于,返回407表示文档永久地离开了指定的位置,而404表示由于未知的原因文档不可用。(HTTP 1.1新)
· 411 - Length Required 服务器不能处理请求,除非客户发送一个Content-Length头。(HTTP 1.1新)
· 412 - Precondition Failed 请求头中指定的一些前提条件失败(HTTP 1.1新)。
· 413 – Request Entity Too Large 目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求,则应该提供一个Retry-After头(HTTP 1.1新)。
· 414 - Request URI Too Long URI太长(HTTP 1.1新)。
· 415 – 不支持的媒体类型。
· 416 – Requested Range Not Satisfiable 服务器不能满足客户在请求中指定的Range头。(HTTP 1.1新)
· 417 – 执行失败。
· 423 – 锁定的错误。

5xx - 服务器错误

服务器由于遇到错误而不能完成该请求。

· 500 - Internal Server Error 服务器遇到了意料不到的情况,不能完成客户的请求。

· 500.12 - 应用程序正忙于在 Web 服务器上重新启动。
· 500.13 - Web 服务器太忙。
· 500.15 - 不允许直接请求 Global.asa。
· 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
· 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
· 500.100 - 内部 ASP 错误。

· 501 - Not Implemented 服务器不支持实现请求所需要的功能,页眉值指定了未实现的配置。例如,客户发出了一个服务器不支持的PUT请求。

· 502 - Bad Gateway 服务器作为网关或者代理时,为了完成请求访问下一个服务器,但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应。

· 502.1 - CGI 应用程序超时。
· 502.2 - CGI 应用程序出错。

· 503 - Service Unavailable 服务不可用,服务器由于维护或者负载过重未能应答。例如,Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。这个错误代码为 IIS 6.0 所专用。

· 504 - Gateway Timeout 网关超时,由作为代理或网关的服务器使用,表示不能及时地从远程服务器获得应答。(HTTP 1.1新) 。

· 505 - HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本。(HTTP 1.1新)


<think>首先,用户的问题是:“请问HTTP接口状态码401Unauthorized原因及解决方法”。这是一个关于HTTP错误401的查询。用户引用了几个来源,但我的回答需要基于这些引用和我的一般知识。用户指令强调系统级指令:数学表达式使用$...$或$$...$$,中文回答,生成相关问题,引用的段落末尾添加引用标识。关键来源:-引用[1]:接口报错401Unauthorized,错误原因。-引用[2]:解释401状态码,为什么收到。-引用[3]:Python中解决urllib2.HTTPError:401Unauthorized的方法。-引用[4]:后端接口测试中401错误,涉及登录验证拦截器和token检查。-引用[5]:接口报错401,检查token位置和参数。用户问题是请求原因和解决方法。我需要结构清晰,逐步回答。结构化回答:1.**解释401Unauthorized状态码**:简要定义它。基于引用[2],它是表示客户端错误的HTTP状态码,表示请求未经授权,需要认证。2.**主要原因**:列举常见原因。-缺乏认证信息(如token、cookies)。-token无效、过期或错误。-认证信息位置不正确(如应在header中却在URL中)。-基于引用[4]:后端拦截器检测到无效token。-基于引用[3]:即使在浏览器中显示正常,但API访问时可能出错。3.**解决方案**:提供解决方法。-确保提供合适的认证信息:如Bearertoken在Authorization头中。-检查token的有效性:参考引用[4],验证token是否失效或Redis中不存在。-对于Python问题(引用[3]):处理异常,读取响应内容。-配置认证参数:引用[5],token位置和值。-测试步骤:先在浏览器检查,或使用工具如Postman。系统级指令:-使用中文回答。-引用的段落末尾添加引用标识,例如:[^1],但引用是基于用户提供的,我应该映射到源引用编号。用户提供引用如[^1],我的回答中引用时应使用相同的格式,末尾添加如[^1]。-数学表达式:在这个主题中可能不多,但如果有统计等,用正确格式。这里可能不适用。-生成相关问题:回答结束后,添加相关问题部分,如指令中§§相关问题§§。完整回答结构:-以清晰的方式逐步解释原因和解决方法。-整合引用:当提到具体点末尾加引用。例如:引用[2]解释状态码:"401Unauthorized是一个表示客户端错误的HTTP状态码..."[^2]。-生成相关问题:-类似示例,添加§§相关问题§§部分。确保真实可靠:基于标准HTTP知识和引用。大纲回答:1.**引言**:简要重述问题。2.**什么是HTTP401Unauthorized**:定义和原因概述。3.**常见原因**:-请求中缺少认证信息。-Token无效或过期。-认证信息格式或位置错误。-后端验证失败(如引用[4])。-浏览器中可能显示但API失败(引用[3])。4.**解决方法**:-添加或更正认证头(Authorization:Bearer<token>)。-检查token获取和存储。-使用工具调试(如Postman)。-处理异常(如Python的try-catch)。-配置后端确保token有效。5.**结语**:总结要点。6.**相关问题**:生成3-4个相关问题。引用的添加:当直接来自引用时,末尾加[^1]等。例如:从引用[2],状态码定义:"...需要身份验证后访问资源。"[^2]。从引用[4],后端代码示例,末尾加[^4]。回答中引用代码块时,如果需要,用代码格式,但指令中没有特别要求,仅在示例中有Python代码。用户引用有代码,我可以简要描述。用户指令:"回答中引用的段落末尾自然地添加引用标识",所以当我引用具体文字时加。例如:如果我说"根据引用,401错误通常表示需要认证",但这可能不需要加,当直接复制或非常具体时加。安全起见,关键点加引用。结尾生成相关问题,例如:-如何正确设置HTTP授权头?-如何在Python中处理401错误异常?-后端token验证的最佳实践是什么?</think> ### HTTP接口状态码401 Unauthorized原因及解决方法 HTTP状态码401 Unauthorized是一个常见的客户端错误,表示服务器无法验证请求的身份是否被授权访问所请求的资源。这通常意味着客户端(如你的API调用或应用)在请求中缺乏有效的认证信息,或者提供的认证信息(如token或凭证)无效或不完整。下面我将基于您的引用和我的一般知识,逐步解释原因和提供解决方案,确保内容清晰、可靠。 #### 1. **HTTP 401 Unauthorized的定义和常见原因** HTTP 401错误是一个表示客户端错误的HTTP状态码,用于指示请求未经授权。服务器会返回状态码来告知客户端需要提供有效的身份认证后,才能允许访问资源。根本原因是认证失败,具体可能包括: - **缺少认证信息**:请求没有包含必要的认证头部(如Authorization头),或认证参数(如token)缺失[^2]。 - **认证信息无效或过期**:如果提供了token或其他凭证,但它们可能已过期、被撤销,或与服务器存储的不匹配。例如,引用[4]中提到后端通过Redis验证token时,如果token不存在或失效,服务器会返回401[^4]。 - **认证信息位置或格式错误**:Token可能被错误地放置在URL参数或Cookie中,而不是标准的HTTP头部。引用[5]强调需要检查token的存储位置(如是否在Authorization头中)以及参数值是否正确[^5]。 - **后端验证逻辑问题**:在服务端代码中,拦截器或验证层可能抛出异常(如JWT token解析失败或Redis查询为空),导致直接返回401。引用[4]中的后端代码展示了这种拦截器机制[^4]。 - **客户端处理异常**:如引用[3]的Python案例所示,即使浏览器访问正常显示页面,但API调用时(如使用urllib2)可能触发401错误,因为客户端未正确处理认证或读取响应内容[^3]。 总的来说,这些原因通常与身份验证的配置或实现错误相关。在开发环境中,这类错误常见于API测试、前后端分离系统或依赖token认证的场景(如OAuth或JWT)。 #### 2. **解决方法:如何排查和修复401 Unauthorized错误** 解决401错误需要逐步检查客户端和服务端环节。以下是基于引用和最佳实践的推荐步骤: ##### **步骤1: 检查并添加认证信息** - **确保认证头部正确设置**:在HTTP请求中,Authorization头是标准方式。格式应为 `Authorization: Bearer <token>` 或类似(如Basic认证)。引用[2]和[5]指出,许多错误源于token参数名或值错误。使用工具如Postman或cURL验证请求头是否正确[^2][^5]。 - 示例Postman设置:Header中添加键 `Authorization`,值 `Bearer eyJhbGciOi...`。 - **验证token来源和有效性**: - 如果token来自登录API,确认它未被过期或服务器已刷新(引用[4])。后端代码中检查Redis存储是否匹配token[^4]。 - 使用工具(如jwt.io)解析token内容,确认其有效性和过期时间。 - **检查token位置**:引用[5]强调token可能位于URL参数(如 `?token=value`)或Cookie中。确保请求与服务器要求的格式一致[^5]。 ##### **步骤2: 客户端调试和处理异常(针对特定语言)** - **Python等编程语言**:如引用[3]所述,处理 `urllib2.HTTPError: 401` 时,捕获异常并读取响应内容。Python代码示例: ```python import urllib2 from urllib2 import HTTPError import zlib # 用于gzip解压缩,如果服务器响应的内容编码是gzip try: response = urllib2.urlopen('http://example.com/api') except HTTPError as e: if e.code == 401: # 读取响应内容,即使状态码401 content = e.read() if 'gzip' in e.headers.get('content-encoding', ''): content = zlib.decompress(content, 16 + zlib.MAX_WBITS) # 解压gzip数据 print("Error content:", content) # 分析内容以诊断问题 ``` 此方法确保从异常中提取详细信息(如错误页面),避免忽略潜在线索[^3]。 - **浏览器与API区别处理**:引用[3]提到浏览器可能显示401页面但API失败,因为客户端需要显式处理认证。确保在代码中实现重试机制或日志记录[^3]。 ##### **步骤3: 服务端配置与验证** - **检查后端拦截器和验证逻辑**:引用[4]的后端代码显示了一个Spring Boot拦截器示例。问题常出现在token验证步骤: - 确保 `Authorization`头从请求中正确提取(使用 `request.getHeader("Authorization")`)。 - 后端存储如Redis中查询token是否存在。如果失效( `redisToken==null`),返回401。代码中添加了拦截器排除路径(如 `/user/login`),但这可能误伤其他路径。优化方法:日志记录或细化排除规则[^4]。 - 测试建议:在本地运行后端,用无效token发送请求,检查拦截器是否返回正确状态码。 - **通用服务端修复**: - 更新认证配置(如JWT密钥或过期时间)。 - 确保服务器响应包含WWW-Authenticate头(如 `WWW-Authenticate: Bearer realm="example"`),以指导客户端(RFC 7235标准)。 - **工具辅助**:使用日志系统(如ELK或Sentry)监控API请求,定位失败点。 ##### **步骤4: 整体测试和预防** - **测试策略**: - **先易后难**:先用浏览器或Postman手动验证API(引用[3]建议)。如果401消失,问题在客户端代码[^3]。 - 自动化测试:添加单元测试模拟401场景(如用Mock token)。 - **预防措施**: - 使用API网关管理认证(如Kong或Auth0)。 - 定期更新token刷新机制。 - 文档化认证需求,避免位置混淆(如清楚说明token必须放在头部)。 - **资源检查**:确保目标API不需要其他权限(如IP白名单或OAuth作用域)。引用[2]提到,服务器拒绝授权的深层原因可能涉及访问策略[^2]。 #### 3. **总结与要点** HTTP 401错误的核心是认证失败。处理时应: - **客户端侧**:检查请求头、token有效性和位置;代码中处理异常。 - **服务端侧**:验证拦截逻辑和token存储。 - **工具**:利用Postman调试或日志分析。 - **根据引用关键点**:引用[1]-[5]强调token检查和位置的重要性[^1][^2][^3][^4][^5],成功率提升后,API调用通常返回200 OK。 如果问题持续,请提供更多细节(如具体API代码或请求示例),以便进一步分析。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

宋哈哈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值