美文网首页
controller从前端请求的body中获取参数

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

作者: 猫尾草 | 来源:发表于2019-06-12 16:55 被阅读0次

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

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 }),这个注解的意思是ServletDispatcherServlet或者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. 参考

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

相关文章

网友评论

      本文标题:controller从前端请求的body中获取参数

      本文链接:https://www.haomeiwen.com/subject/uznsfctx.html