今天天气晴朗，天气刚刚好，心情格外美好。但是业务同学突然说生产环境出了bug。不好意思，收回前言，感觉台风过境。..检查后报413错误，说明http请求实体太大。这个错误一般出现在使用http请求上传文件的时候，因为上传文件容易出现大文件，比如超过5m的文件。但是今天造成这个问题的原因是前端post请求发送的json对象太“大”了，大约108k，查了一下感觉很奇怪。,100k左右应该是问题的分界线。检查没有产生日志后，基本可以确定不是后台代码的问题。分析http请求经过的路径节点：**前端请求**—>**节点服务转发**—>**跳板机**—>**Nginx转发**—>**后台Tomcatservice**——>**后台代码**第一反应是不是Nginx的配置导致的。记得之前上传一个文件报413，因为文件大小是8M，超过了Nginx的配置。上限造成的。于是第一时间联系了ops，他们查了结果：client_max_body_size5M；（请求主体缓冲区大小）client_body_buffer_size128k；(clientrequestbodybuffersize)所以没有问题。为了保险起见，client_max_body_size改成了20M，但是问题还是存在，所以不是Nginx配置的问题。这是我关注Tomcat赚来的。在Tomcat的server.xml中，maxPostSize参数会限制post请求消息体的最大值。继续找ops，发现server.xml中没有配置这个参数。检查后，没有配置。当默认值为2M（2097152（2兆字节））时，没有问题。..嗯嗯嗯。...因为前后端分离，不清楚前端的实现是否会限制post消息体的大小。虽然我自信后端代码不会有问题，但是我还是先用postman测试了后端，发现即使是1M的数据，也没有问题。因此，结果是显而易见的。问题基本出在三个地方：前端请求、节点服务转发、跳板机。找了前端同学一探究竟。原来他们的节点服务使用的是Egg.js框架，Egg的配置jsonLimit会限制json消息体的大小。如果不配置，默认为100k。修改为5M后问题解决。完美的。
