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