接口访问报错:The valid characters are define…

2019-08-16 10:05:36来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

接口访问报错:The valid characters are defined in RFC 7230 and RFC 3986

 

写了个接口,在测试访问的时候,需要传json串,但是后台报错了

The valid characters are defined in RFC 7230 and RFC 3986

当前使用的tomcat版本:apache-tomcat-8.0.53

 

 

 一、方案一(修改后被源码覆盖,无法修改文件):


在tomcat/conf/catalina.properties中添加下面这句话 tomcat.util.http.parser.HttpParser.requestTargetAllow=|{} 在tomcat/conf/service.xml中在Connector标签中添加URIEncoding="UTF-8"、relaxedQueryChars="[]|"、relaxedPathChars="[]|" 而我使用的tomcat8中catalina.properties文件中已经有了这句话,打开注释即可。 清理tomcat后,重启后还是无效,打开catalina.properties和service.xml查看,修改的内容自动恢复以前的状态,重试多次也如此,修改过用户操作文件权限也还是这种情况,真的很纳闷!!!

  

 

 

二、方案二(修改后重启tomcat无效)
在tomcat的vm中添加:-Dcatalina.config="J:\DevelopTool\apache-tomcat\apache-tomcat-8.0.53\backup\catalina.properties"


看网上的Tomcat源码分析-CatalinaProperties类
这个类很简单,就是一个属性获取的公共类。但是用法却很巧妙,代码相当优雅,所以忍不住想要再说说这个类。
它的功能是管理catalina.properties类文件中的配置属性获取,只有一个方法getPropertity(String name).

 

我认为这个类的高明之处就是充分使用了配置属性,配置文件路径可配置,即流程图的第一个操作,是从环境变量中获取的配置文件路径。如果我通过VM参数配置-Dcatalina.config=”xxx/myfile/catalina.properties”的话,就改变了它的默认的配置文件。

  

方案二内容引用来源:https://blog.csdn.net/wojiushiwo945you/article/details/72865427

 

 

 

Tomcat源码分析-CatalinaProperties类

引用来源:https://blog.csdn.net/guo20082200/article/details/80558151

 


分析原因:
第一种方案还不确定行不行,第二种方案试验不行。经过第二种方案的阅读发现,第一种方案没有成功的原因是tomcat会生成catalina.properties

文件覆盖你自己修改后的catalina.properties文件,于是我先用tomcat的clean将项目编译成class文件,然后修改catalina.properties后

直接启动服务,然后访问接口成功了。

 


第二波bug的出现
由于参数中json串过大(20kb左右),请求接口的时候又报出了错误

http post request header is too large

 

在tomcat/conf/service.xml中在Connector标签中添加maxHttpHeaderSize ="102400"和maxPostSize="-1",如下

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"
  URIEncoding="UTF-8"
  relaxedQueryChars="[]|"
  relaxedPathChars="[]|"
  maxHttpHeaderSize ="102400"
  maxPostSize="-1"/>

说明: maxPostSize="-1"(代表POST数据大小限制,在tomcat7.0.63之前,设置为0和负数均可以代表不限制;在tomcat7.0.63之后,不可以设置为0,只能是负数代表不限制)

使用postman测试接口,post请求,body下form-data和x-www-form-urlencoded均可以请求成功,如果请求参数数据量太大,不设置maxPostSize可能会报错。

参考来源:https://blog.csdn.net/whatever8975757/article/details/60576188

 

 


第三波bug的出现
接口调试完成后,部署到测试环境时(环境中的tomcat均已修改),访问接口又报出错误

Nginx 414 Request-URI Too Large

 

原因是请求头的长度超出了nginx限制,在nginx.conf里面把这两个缓存加大就行
client_header_buffer_size 512k;
large_client_header_buffers 4 512k;

 

 

打开文件
vim /usr/local/nginx/conf/nginx.conf
按i进行编辑,并添加上面两行代码,按Esc退出编辑,按:wq!保存
进入nginx可执行目录sbin下
cd /usr/local/nginx/sbin/
重启nginx
./nginx -s reload


再次访问接口的时候就正常了。

 
 
 

 


原文链接:https://www.cnblogs.com/yangtsecode/p/11160399.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:feign服务端出异常客户端处理的方法

下一篇:类初始化与实例初始化