作者:京东批发 李文龙
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 中。
此文是笔者依照剖析流程进行简略验证,剖析验证过程中不免有脱漏之处,如有谬误脱漏还烦请各位指出共同进步。