axios v1.19.0 升级后报 ERR_INVALID_URL如何修正协议后缺少 // 的畸形 URL【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios如果你的项目把 axios 升级到 v1.19.0 后原本能发出去或被 URL 解析器悄悄“纠正”的请求开始抛出AxiosError错误码为ERR_INVALID_URL并且message里写着missing // after protocol那么问题出在你传给 axios 的url或baseURL上字符串写成了https:example.com、https:/example.com这类协议后缺少//的形态。v1.19.0 起axios 会直接拒绝这类请求而不是像以前那样依赖浏览器或 Node.js 的 URL 解析器去做规范化。本文说明如何定位是哪个配置值出了问题、如何修正、以及如何验证请求恢复。v1.19.0 的行为变化按照 升级指南 中 “Upgrading to v1.19.0” 一节的说明请求现在会拒绝http:或https:开头、但协议后省略//的url或baseURL应把https:example.com、https:/example.com这类值替换为格式完整的 URL例如https://example.com产生的AxiosError使用错误码ERR_INVALID_URL并在消息中给出已经做过安全脱敏的出错 URL。这是一个有意为之的安全变更此前畸形 URL 可能被浏览器或 Node.js 的 URL 解析器静默规范化从而绕过baseURL或 URL 白名单的限制。错误处理文档 也把ERR_INVALID_URL定义为 “Invalid URL provided for axios request”并在 “Malformed HTTP(S) URLs” 一节中给出了同样的规则。如何定位出错的 URLaxios 抛出的是标准结构的AxiosError可用字段包括message、code、config等字段定义见 error-handling 文档 开头的表格。定位这个错误主要看两个字段error.code为ERR_INVALID_URLerror.message会直接点出出错 URL。文档给出的示例消息文档示例为Invalid URL https:example.com: missing // after protocol读消息时有三点需要注意它们决定了你能不能从消息里直接还原出原始配置值消息中的 URL 是脱敏后的。axios 会对消息中的 URL 做控制字符规范化并隐去凭据、查询参数值保留参数名和 fragment 内容替换为[REDACTED ****]标记scheme、host、path 和参数名会保留保证请求仍可被识别。所以如果你的 URL 里带了user:passhost、查询参数值或#fragment消息里看到的会是脱敏后的形态主机名和路径仍然是定位依据。脱敏是无条件的。AxiosError.message总是会被toJSON()包含进序列化结果而请求配置里的redact选项只能作用于config的键值无法清理已经生成的 message见 error-handling 文档 对 message-level redaction 的说明。消息里显示的是规范化后的字符串。单元测试 覆盖了带控制字符的输入前导制表符的\thttps:example.com/users、协议中间夹换行的h\nttp:example.com/users等都会抛出同样的错误而消息中显示的是规范化后的 URL。也就是说即使你的原始字符串里混进了不可见字符消息仍然指向真正的目标 URL。被检查的是哪些值检查逻辑位于 buildFullPath请求的url总是会被检查baseURL只在真正参与 URL 拼接时才会被检查即请求url是相对路径或者你把allowAbsoluteUrls设为false该配置决定绝对url是否会覆盖baseURL默认true。这一点有测试佐证当请求url是绝对 URL 时一个畸形的baseURL不会被触发报错但当allowAbsoluteUrls为false强制走baseURL拼接时同一个畸形baseURL就会抛出ERR_INVALID_URL见 buildFullPath.test.js 中 “does not reject an unused malformed baseURL for absolute requests” 与 “rejects a malformed baseURL when absolute requests are forced through baseURL” 两个用例。实际排查时的含义是axios.create({ baseURL: ... })里配置的baseURL和请求级传入的url、baseURL都要查一遍出错的往往是和消息中主机名、路径对得上的那一处。修正 URL修正方式就是升级指南给出的直接建议把缺少//的值改写为格式完整的 URL。// 修正前协议后缺少 //v1.19.0 起会抛 ERR_INVALID_URL axios.create({ baseURL: https:api.example.com/v1, }); // 修正后 axios.create({ baseURL: https://api.example.com/v1, });// 修正前请求级 url 只写了一个斜杠 axios.get(https:/api.example.com/users); // 修正后 axios.get(https://api.example.com/users);上面的域名取自文档中的示例值替换成你项目里实际出错的值即可判断依据就是错误消息中保留的 scheme、host 和 path。如果消息里的敏感部分已被脱敏用主机名和路径与代码里的配置对号入座而不是去猜。验证修正结果修正后重新发起之前失败的请求判定标准是请求不再以ERR_INVALID_URL被拒绝而是按正常流程发出并返回响应。你可以沿用 error-handling 文档 给出的捕获模式来确认axios.get(https://api.example.com/users).catch(function (error) { console.log(error.code); // 修正前为 ERR_INVALID_URL修正后不应再出现 console.log(error.message); console.log(error.config); });如果修正后error.code不再是ERR_INVALID_URL、请求正常得到响应说明 URL 形态问题已解决若baseURL相关的问题在部分请求上仍存在检查这些请求是否走了相对url拼接路径或是否配置了allowAbsoluteUrls: false把对应的baseURL一并改成//形态。边界说明该检查只针对http:和https:两种协议error-handling 文档 的表述与 buildFullPath 中的正则/^https?:(?!\/\/)/i一致其他协议字符串不在本次变更的拒绝范围内。这条规则对url和baseURL同样适用request-config 文档 在baseURL一节中也明确写了 “The same well-formed URL rule applies tobaseURL”。如果你的 URL 值来自不可信输入request-config 文档 提醒baseURL是 URL 拼接便利设施而非安全边界allowAbsoluteUrls: false可以防止绝对url替换baseURL但不会校验或约束相对路径对不可信来源的url应在传给 axios 之前自行校验。参考文档升级指南、错误处理、请求配置、URL 拼接实现、buildFullPath 测试。【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考