1. 背景
“俗话说：为了修复一个小 bug 而引入了一个更大 bug”
因所负责的系统使用的 spring 框架版本 5.1.5.RELEASE 在线上出过一个偶发的小事故，最后定位为 spring-context 中的一个 bug 导致的。
为了修复此 bug 进行了 spring 版本的升级，最终定的版本为收银台团队使用的版本 5.2.12.RELEASE，对应的 springboot 版本为 2.2.12.RELEASE。
选择这个版本的原因是：
1. 有团队经过了长时间的线上验证
2. 修复了 5.1.5.RELEASE 对应的 bug
2. 升级上线
升级相关版本后在预发环境进行了验证，暂未遇到关于框架的问题。本以为安全升级完成，在上线过程中发现在 APP 中无法访问，此时还未挂载流量。
日志中分析是某些参数未解析到，后在 nginx 日志中查到相关请求，使用 postman 模拟请求可以正常使用。
3. 分析验证定位原因
1. 临时修复
在代码一致的情况下，唯一的可能就只能是线上与预发配置不同，经对比分析得出是某个过滤器的顺序在线上未配置，按照预发的配置后可正常使用。我们暂且称修改的这两个过滤器为 M 和 A,
其中默认情况下执行顺序为 M->A，顺序修改为 A->M 后正常，其两者作用大致为：
M:通用过滤器，解析 url 中的参数至 parameterMap 中，并初始化读取了 body 中的 inputstream 进行了 byte 数组的缓存，用于解决重复读取流问题A:特定处理器，先是查询 parameter 中的参数，然后逻辑处理后再设置一些特殊参数。
2. 为何需要改过滤器顺序
经查未升级前过滤器的顺序与升级后过滤器顺序一致，为何升级 spring 框架后需要修改配置。此时猜测可能是 spring 在升级过程中修改了一部分代码，
但未有头绪，只能先调转方向分析为什么 postman 和浏览器中的 swagger 可以正常使用
3. 分析 nginx 日志
前端请求与 postman 请求的 nginx 日志进行了分析得出了原因，对比日志如下：
postman：POST /shop/bpaas/floor?client&clientVersion&ip=111.202.149.19&gfid=getShopMainFloor&body=前端:POST /shop/bpaas/floor HTTP/1.0\” 200 634 \”-\” \”api\” \”0.94\” 0.008 0.007 client&clientVersion&ip=111.202.149.17&gfid=getShopMainFloor&body=
经过以上对比发现虽然 postman 使用了 post 请求，但数据还是放置在 url 中，在经过系统的一个内置过滤器 M 时将 url 中的参数解析到了 parameterMap 中，后续过滤器可以使用
request.getParameter 获取到，注意此方法是解决问题的关键，此时还未意识到。
4. 升级前后框架是否有大的修改
因升级的版本是升级了一个小版本号，所以不好对比升级的 buglist，只能慢慢进行分析，后在分析过滤器时发现升级 spring 后过滤器个数由 11 个减少到了 10 个，减少了那一个为：org.springframework.web.filter.HiddenHttpMethodFilter
此过虑器的作用是在浏览器不支持 PUT、DELETE、PATCH 等 method 时，可以在 form 表单中使用隐藏的_method 参数支持这几种 method。好像跟参数解析没有任何关系，
继续分析升级版本中 （由 2.1.3.RELEASE->2.2.12.RELEASE）是否修改了此过滤器的一些内容，后在 2.2.0.M5 的 release notes 中发现 HiddenHttpMethodFilter 相关的：
“ Disable auto-configuration of HiddenHttpMethodFilter by default ” github 上对应的版本 release notes： https://github.com/spring-projects/spring-boot/releases/tag/v2.2.0.M5
也就是说升级后 HiddenHttpMethodFilter 默认配置由 enable 修改为了 disable，如果再修改回去是不是可以修复参数解析的问题呢？
5. 添加过滤器 enable 配置
因 bug 修复列表中有对应的 issues，所以找到了此过滤器对应的配置：
-Dspring.mvc.hiddenmethod.filter.enabled=true
添加后可以正常使用，证明是此过滤器中在某种条件下不可缺少。
6. 未升级 spring 版本时 disable 验证
在确认未升级版本的 spring 支持此参数的情况下，添加了以上参数，将默认的启动修改成了禁用，经验证：在不代码修改的情况下，无此过滤器时参数无法解析。证明了上步的猜测。
7. 深入源码分析
此时需要分析 HiddenHttpMethodFilter 过滤器中是否有特殊操作，源码如下：
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
HttpServletRequest requestToUse = request;
if (\”POST\”.equals(request.getMethod()) && request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE) == null) {
String paramValue = request.getParameter(this.methodParam);
if (StringUtils.hasLength(paramValue)) {
String method = paramValue.toUpperCase(Locale.ENGLISH);
if (ALLOWED_METHODS.contains(method)) {
requestToUse = new HttpMethodRequestWrapper(request, method);
}
}
}
filterChain.doFilter(requestToUse, response);
}
分析以上源码可以发现，有且只有一种可能，就是 request.getParameter 可能是解决问题的是关键。
8. 大胆猜测
分析后源码猜测，第一步中的修改顺序有可能是 A 中有调用 getParameter，所以顺序调整为 A->M 后，相当于间接使用了 HiddenHttpMethodFilter。
9. 开始验证
在不使用 HiddenHttpMethodFilter 的情况下，如果在过滤器原有顺序不修改的情况下，只要在 M 执行前调用了 request.getParameter，理论上可以正常为使用。所以在 debug 情况下
利用工具在 M 过滤器调用前先行执行 request.getParameter，发现的确可以正常使用。
10. 分析过滤器
先前简述了 M 的功能，主要是包装了 request，后读源码时发现，如果是 post 请求，读取 body 体中的数据后并未解析 body 中的参数至 parameterMap 中，而代码中的其它过滤器都是
通过 request.getParameter 获取的数据，重写后的代码：
public String getParameter(String name) {
if ( this.parameterMap.containsKey(name) )
return this.parameterMap.get(name);
else {
return super.getParameter(name);
}
}
在经过 request 包装后，先是从 paremeterMap 中获取数据，此时 map 肯定是没有数据，只能从父类获取，而父类获取时会解析 parameter，解析时使用到了 inputStream，但 M 过滤器
的在初始化时解析了输入流，此时 tomcat 内部使用内部的 request 获取 stream 时将获取到空数据，即无法从 parameter 中获取到 body 体中的数据。
而如果在调用 M 前调用了 request.getParameter，tomcat 内部将提前于 M 解析 parameter，可以保证后续可获取到相关参数。
4. 修复方案
既然得出了结论，那么升级 spring 版本后修复此 bug 可选择的方案就比较多了，主要有：
1. 启用 HiddenHttpMethodFilter，添加对应的参数，保证升级前后过滤器个数与顺序一致
2. 调整理过滤器 A 与 M 的顺序，保证 M 在 A 之前执行即可。
3. 修改过滤器 M 内部的逻辑，不在初始化的时候解析 body，或是在解析 body 后将参数重新放置到 parameterMap 中。
此文是笔者按照分析流程进行简单验证，分析验证过程中难免有遗漏之处，如有错误遗漏还烦请各位指出共同进步。
