于一次简单的get请求得知tomcat的一个小坑

一、前言

在接到需求后很快的做完了然后做本地测试发现：

java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

因为是get请求里面参数数据是查询人名所以携带中文，对此进行了问题分析。

二、分析过程

在当时我就立马咨询了百度老师，是因为Tomcat在某个版本里面升级了，对URL遵守RFC规范，对特殊字符不予以放行。
要解决问题有两个方向：

1.解决编码问题。
2.Tomcat降版本。

使用postman携带中文参数可以正常访问到数据，之前也没有遇到过这样的问题，因此java服务端是没问题的，而且服务是使用springboot 1.5.3 ，对应的Tomcat版本是8.5.14，不考虑打成war包部署就打算从编码入手了。

其实问题说起来还是挺简单的。。但是因为服务设计的框架所以走错了路子。。。想记录一下分析的过程。

从前端那里携带中文参数访问Tomcat，在Tomcat的访问日志里，看到了携带中文参数的请求是这样的：

[18/Jun/2019:19:51:18 +0800] 0:0:0:0:0:0:0:1 "GET null null" 400 (0 ms)

请求都没进来就被过滤掉了。

我在js里面对参数进行了编码

window.location.href='?p=ware&d=ware-register-query&agentName='+encodeURI($(".agent").val());

在这里对参数进行了编码 ，发现并没有用。百思不得其解。

其实因为我们是 html+php+java架构的，请求是经过php处理后再发送到java后台的，在js中编码过的参数，发送到php处理的时候，会自动解码：

var_dump(check_merchant_query.'?agentName='.$_GET['agentName']); // 打印拼接的url
$req = new httpRequest('get',check_merchant_query.'?agentName='.$_GET['agentName'],null,function($result){return $result;});

这里打印出来的结果是已经解码过的，当时没注意到，只是觉得这个url没错，因此多花了许多时间。。
以为在PHP里面构造的http请求的get参数是已经编码过的，所以我将接下来的时间都放在了如何设置tomcat对特殊字符放行上。。

如果是正常的html+java，那么上面的编码就是没问题的，只是分析的时候忘记了还要经过php处理。。

最后在Php中对参数进行编码就可以啦

$req = new httpRequest('get',check_merchant_query.'?agentName='.urlencode($_GET['agentName']),null,function($result){return $result;});

至于postman为什么能够输入中文参数就能够直接访问tomcat呢？是因为postman就相当于一个浏览器，在发送请求的时候已经对参数进行了编码操作啦