共计 3687 个字符，预计需要花费 10 分钟才能阅读完成。
作者：京东批发 李文龙
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 可抉择的计划就比拟多了，次要有：
- 启用 HiddenHttpMethodFilter，增加对应的参数，保障降级前后过滤器个数与程序统一
- 调整理过滤器 A 与 M 的程序，保障 M 在 A 之前执行即可。
- 批改过滤器 M 外部的逻辑，不在初始化的时候解析 body，或是在解析 body 后将参数从新搁置到 parameterMap 中。
此文是笔者依照剖析流程进行简略验证，剖析验证过程中不免有脱漏之处，如有谬误脱漏还烦请各位指出共同进步。
