Axios中的参数为啥没被完全编码

起因

在一次需求开发自测中遇到一个问题,一个接口的cateId3List参数中有未编码中括号('['、']'),是url特殊字符,但在发这个Get请求时参数未完全被编码,在测试环境会导致服务端返回400错误,线上环境会概率性的400 Bad Request(和nginx层无关)。


ps.该项目网络请求使用的是axios,这个接口在发出时没做过多的处理(可以理解成和用原生的axios发出请求是一样的);下面都是以axios.get的方式为例来探讨下这个问题axios版本0.19.2)

问题定位

当时为了不阻塞测试流程,就先让QA通过在fiddler配置规则绕过了这个问题,使用的是fiddler自带的rewrite功能。


这里rewrite做的事就是把请求参数的[]给替成编码后的。

根据以往使用axios的经验,我们在发请求时传入的参数明明是不需要主动预编码的,这里为什么会出问题呀!使用时,我们会像下面例子这样:

const axios = require('axios');
const argString = '你好';
axios.get('/zzopen/sellbook/searchDefaultWord', {
  params: {
    arg: argString
  }
}).then(function (response) {
  console.log(response);
})

通过抓包发现发出去的请求,你好 确实已经被编码成 %E4%BD%A0%E5%A5%BD,我们并没有手动的去编码,这一切看起来都是理所当然的。

接下来,我们把上面请求的代码修改成这样:

const axios = require('axios');
const argString = JSON.stringify(["你", "好"]);//"["你","好"]"
axios.get('/zzopen/sellbook/searchDefaultWord', {
  params: {
    arg: argString
  }
}).then(function (response) {
  console.log(response);
})

这时再看下发出去的请求:

抓包发现和我们预想的不太一样,原本认为["你", "好"]应该编码成 %5B%22%E4%BD%A0%22%2C%22%E5%A5%BD%22%5D ,而实际上却是 [%22%E4%BD%A0%22,%22%E5%A5%BD%22],这不符合我们的预期呀,只编码了[]中间的内容,而中括号直接忽略了。想不明白呀,我们只能带着疑问去看看axios源码(https://github.com/axios/axios)搞啥子了,功夫不负有心人,最终找到了关键性的代码buildURL.js,这里有关键性的代码:

我们继续跟进去看下encode方法的实现:

发现在这里会组装Get请求参数,外面传入的参数会在这里构造后拼接到url后,但是特殊的点就在这里:进行 encodeURIComponent 后,会在把部分encode后的参数的通过正则的方式在还原成了原本的字符了,What  ???


为什么

问题看到这里从源码上也看不出来啥子了。又看了下提交历史,这块代码的修改首次提交时间2015年7月,看来是个历史悠久的问题。

但是为什么要加上这些代码呢,提交注释里只有don’t escape square brackets。当问题不知如何下手时,就只能去怀疑猜测了。然后就想着是不是URL规范就这么规定的????,然后就去看看URI(URL是URI的子集)的规范。这里就要提到rfc3986(主要原因在这个规范里),内容比较多感兴趣的可以到这里查看https://tools.ietf.org/html/rfc3986,网上也有中文的 版的,大家感兴可以去看看。在规范中提到URL只允许包含四种大类的字符(也称非保留字符):

  1. 英文字母(a-zA-Z)

  2. 数字(0-9)

  3. -_.~ 4个特殊字符

  4. 保留字符,RFC3986中指定了保留字符(英文字符)为: ! * ' ( ) ; : @ & = + $ , / ? # [ ]

看到这里心里大概就个底了,原来[]是可以不用在进行编码的(编码了也没啥问题)。

再说说这个规范谁制定的,ietf,主要工作是负责互联网相关技术标准的研发和制定,是国际互联网业界具有一定权威的网络相关技术研究团体。说白了互联网标准就是这货制定的,用前端的JS视角比喻的话,就有点类似TC39,rfcxxx类似ECMAScript标准。这个规范早在2005年就制定了,为啥到现在还没有完全普及,说到这就和前端的场景更像了,虽然都是标准,但是别人可以不实现,晚实现(eg.浏览器对各语法的支持情况)。到这里编码的问题,我们了解了大致的来龙去脉。

不过,还有疑惑未解,上面还提到了概率性的400 Bad Reques,这个由于啥原因呢,想要得到答案只能从后端/运维下手了,后面和运维同学沟通了解到知道,运维 只对个别机器的tomcat做过临时的兼容配置到这里答案就明了了。

如果想通过后端的方式来处理的话,就是修改Tomcat提供的配置字段(conf/catalina.properties),让其兼容需要的字符:

我们要怎么改

这里撇开服务端去修改Tomcat这类的配置,来谈谈前端有哪些解决方法。

  • 修改请求为post

当时遇到这个问题时,没时间过多的去追究原因,就改用post请求来规避这个问题,现在回看下,post方式是规避了axios对参数的encode。

  • 修改axios源码

关于这一点,在GitHub上有人提了Pull request #2563 提了,但是最终被关闭未能合并到主分支上。如果要修改的话,可以参考这个 commit id的写法:

  • 参数直接拼接URL上

从axios源码上看,我们也可以预先把请求参数拼接到URL上,然后axios就不会再对处理,像这样:

const axios = require('axios');
const argString = JSON.stringify(["你", "好"]);//"["你","好"]"
axios.post('/zzopen/sellbook/searchDefaultWord?arg=' + encodeURIComponent(argString))
  .then(function (response) {
  console.log(response);
})

可以看到参数正常编码了

  • 使用paramsSerializer处理

axios给出的建议如果参数不满足默认的编码方式的话,可以通过paramsSerializer进行自定义编码(序列化),这种方式还是值得推荐的,也能够一劳永逸。

const axios = require('axios');
axios.defaults.paramsSerializer = (params) => {
  return Object.keys(params).filter(it => {
    return params.hasOwnProperty(it)
  }).reduce((pre, curr) => {
    return params[curr] ? (pre ? pre + '&' : '') + curr + '=' + encodeURIComponent(params[curr]) : pre;
  }, '');
};
//正常请求
const argString = JSON.stringify(["你", "好"]);//"["你","好"]"
axios.get('/zzopen/sellbook/searchDefaultWord', {
  params: {
    arg: argString,
  }
}).then(function (response) {
  console.log(response);
})


最后

这个问题,可简单可复杂。往简单的说,我们可以换成post请求完事,仿佛没发生过;往复杂方向去看,需要我们一路往下去深究,不停的问为什么,不停的找答案;回头再看这个过程,其实就是一个自我学习提升的过程。

  • 8
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值