controller从前端请求的body中获取参数

感谢出力甚巨的王二毛同学。事了拂衣去，深藏功与名。

1. 问题的起因

公司某项目，随着功能越来越多，着手进行了拆分。拆分后使用SpringCloud，通过zuul路由串联各微服务模块，各模块使用Sprigboot（这里不讲这个问题）。某天发现其中一个模块的PUT、DELETE请求无法接受前端参数，而GET、POST请求正常，而未拆分之前这些接口都是经过测试的，所以怀疑拆分后有什么改动。着手研究一下。

2. 问题所在

我们先来看一下具体的问题。
conteoller接口：

@PutMapping(value = "/domainName/update")
public String multiDomainName(
      @NotBlank @RequestParam String userName,
            @NotBlank @RequestParam String domainName,
            @NotBlank @RequestParam Integer mode) throws Exception {
    // service操作，这里省略
        return JSON.toJSONString(new RestfulResponseVO());
}

postman发送请求：

postman发送请求.jpg

postman收到的response

{
    "code": "417668737",
    "content": "",
    "data": "",
    "message": "Required String parameter 'domainName' is not present",
    "pageCount": 0,
    "total": 0
}

可以看到，postman以x-www-form-urlencoder的形式发送了三个参数，但是controller接口没有获取到参数。然而如果我们新建一个springboot工程，并把以上代码简单加进去，是可以正常接收参数的。

3. 解决问题的过程

3.1 看一下request

将controller改造成以下：

@PutMapping(value = "/domainName/update")
public String multiDomainName(
              HttpServletRequest request
//          @NotBlank @RequestParam String domainName,
//          @Range(min = 0, max = 2, message = "域名操作为：0-禁用;1-启用;2-删除！") @RequestParam Integer mode
          ) throws Exception {
        System.out.println(request.getRequestURL());
        System.out.println(request.getQueryString());
        System.out.println(request.getParameter("userName"));
        System.out.println(request.getParameter("domainName"));
        System.out.println(request.getParameter("mode"));
    // 读取body里面的内容
        BufferedReader bfr = new BufferedReader(new InputStreamReader(request.getInputStream()));
    String line ;
        while((line = bfr.readLine()) != null) {
            System.out.println(line);
            line = null;
        }
    // service操作，这里省略
        return JSON.toJSONString(new RestfulResponseVO());
}

同样的请求，看一下执行结果：

http://xx.xx.xx.xx:xx/domainName/update   // request.getRequestURL()
null  //  request.getQueryString()
null  //  request.getParameter("userName")
null  //  request.getParameter("domainName")
null  //  request.getParameter("mode")
userName=develop&domainName=http%3A%2F%2Fwww.baidu.com&mode=1  //  request.getInputStream()

从这里可以看到，参数已经传递过来了，而且确实在request的body里面，只是没有转换成parameter，controller接口无法自动获取。
到这里，如果熟悉Springboot接口参数获取方式的人应该就想到了，HttpPutFormContentFilter这个类没起作用（Springboot2.0版本升级为FormContentFilter）（参考博客1），但是我是个菜鸟，并不敢确定，所以走了很多弯路。但是以后再遇到这个问题，我就敢肯定地说，就是这样，哈哈哈哈哈。

3.2 关于FormContentFilter

网上搜到一段话（我不知道真假）：
Springboot使用了spring框架，将Http请求的FORM表单参数从body中转换出来，暴露为Servlet请求参数（param），缺省情况下，Servlet规范仅针对HTTP POST做这样的要求。
最早是加入了HttpPutFormContentFilter，该过滤器针对PUT请求提供了转换功能，后来升级为FormContentFilter，覆盖了Delete请求。
FormContentFilter的源码中有这么一段，从request的body中读取参数，放到param中（整个源码不放了）。

@Nullable
    private MultiValueMap<String, String> parseIfNecessary(HttpServletRequest request) throws IOException {
        if (!shouldParse(request)) {
            return null;
        }

        HttpInputMessage inputMessage = new ServletServerHttpRequest(request) {
            @Override
            public InputStream getBody() throws IOException {
                return request.getInputStream();
            }
        };
        return this.formConverter.read(null, inputMessage);
    }

3.3 由此想到一个解决方法

既然是FormContentFilte不明原因没起作用，那我们就显式的声明一下。在任意一个config文件中加入

@Bean
public FormContentFilter formContentFilter() {
  return new FormContentFilter();
}

再次执行上面的postman请求，得到

http://xx.xx.xx.xx:xx/domainName/update  // request.getRequestURL()
null  //request.getQueryString()
develop  // request.getParameter("userName")  
http://www.baidu.com  //  request.getParameter("domainName")
1  request.getParameter("mode")

可以看到已经能正常获取参数，而且body中的数据已经被读取。

3.4 半路出现的新问题

前端同事说看了一阵代码，提出一个新问题，不修改的情况下，为啥put不行，delete反倒可以呢。
这里不详细赘述过程，只给结果：
因为delete请求使用了“请求伪装”（我也不知道学名叫什么）的方法，用post方法发送请求，但是在参数里面加_method=DELETE来告诉Springboot其实这是一个Delete请求，既使用了POST方法的body->param转换，又不会因为方法不匹配被拒绝请求（参考博客3）。

3.5 最后一个问题，为什么默认的FormContentFilter不见了

我也讲不清楚原理，但是找到了出问题的地方。该项目与其他没有问题的项目的区别是添加了自定义的WebConfig配置。将其注释掉，FormContentFilter就恢复正常了，所以可以肯定这个配置覆盖了FormContentFilter起作用的点。
为什么能想到web配置的问题，还要感谢参考博客4、5中的两位大哥。

4. 深入探究WebConfig覆盖FormContentFilter的原因

该项目的WebConfig类继承了WebMvcConfigurationSupport。
我们知道，WebConfig其实就是替代原来的web.xml，而一般来说我们是不用自己写WebConfig的，Springboot的WebMvcAutoConfiguration类帮我们自动完成了默认的一些配置。但是有时候我们需要添加一些自己的配置，这时候就需要自己的WebConfig配置类。
WebMvcConfigurerAdapter抽象类是对WebMvcConfigurer接口的简单抽象（增加了一些默认实现），但在在SpringBoot2.0及Spring5.0中WebMvcConfigurerAdapter已被废弃。官方推荐直接实现WebMvcConfigurer或者直接继承WebMvcConfigurationSupport。可以通过以下方式实现自己的WebConfig。
方法一：

public class WebConfig implements WebMvcConfigurer {
  // 具体内容
}

方法二：

public class WebConfig extends WebMvcConfigurationSupport {
  // 具体内容
}

看一下WebMvcAutoConfiguration类的代码头部注解：

@Configuration
@ConditionalOnWebApplication(type = Type.SERVLET)
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class,
        TaskExecutionAutoConfiguration.class, ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {
  // WebMvcAutoConfiguration的具体内容，不贴出来
}

头部注解中有两个值得关注的地方，第一个是@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class }),这个注解的意思是Servlet、DispatcherServlet或者WebMvcConfigurer在类路径上，就会启用WebMvcAutoConfiguration；第二个是@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)，这个注解的意思是如果你实例化了WebMvcConfigurationSupport的Bean,那么WebMvcAutoConfiguration就不起作用了。
我们的WebConfig正是继承了WebMvcConfigurationSupport导致了WebMvcAutoConfiguration不起作用，而WebMvcAutoConfiguration有这么一段代码：

@Bean
@ConditionalOnMissingBean(FormContentFilter.class)
@ConditionalOnProperty(prefix = "spring.mvc.formcontent.filter", name = "enabled", matchIfMissing = true)
public OrderedFormContentFilter formContentFilter() {
        return new OrderedFormContentFilter();
}

其中的注解@ConditionalOnMissingBean(FormContentFilter.class)表示如果没有其他地方的声明让Spring实例化一个FormContentFilter的Bean实例，这里就会实例化OrderedFormContentFilter，而OrderedFormContentFilter继承自FormContentFilter。
综上，我们的WebConfig类继承了WebMvcConfigurationSupport,导致了WebMvcAutoConfiguration不起作用，也就不会实例化OrderedFormContentFilter的Bean，从而无法将请求参数完成body->param的转换，而显式地声明一次FormContentFilter的实例化，就可以解决这个问题。
虽然解决了参数的问题，但是WebMvcAutoConfiguration还有很多其他的Bean默认声明，不知道什么时候就会因为缺失导致Bug，所以最好按照官方推荐，当你想配置WebConfig的时候，实现WebMvcConfigurer接口，而不是继承WebMvcConfigurationSupport类。

5. 参考

https://www.jianshu.com/p/cbcb31937af9
https://blog.csdn.net/y75475/article/details/86646265
https://blog.csdn.net/a610786189/article/details/77498306
https://www.oschina.net/question/1457994_2289286
https://www.cnblogs.com/yunquan/p/10655699.html