413错误——线上bug历险记

今天阳光明媚，天气正好，心情很是美丽。

但是业务同学突然说生产环境出bug了。

对不起，收回前言，感觉是台风过境。。
。
查了一下，报413错误，表示http请求实体太大。

此错误通常出现在使用http请求进行文件上传的时候，因为上传文件容易出现大文件，比如超过5m的。

但是今天导致这个问题的是因为前端post请求发送的json对象太“大”了，108k左右，排查了一下，感觉很奇怪，报文体小一点，90多k，没问题，100多k就有问题，100k左右应该就是出现问题的分界线。

看了一下没有日志产生，基本可以确定不是后台代码的问题。

分析了一下http请求经过的路径节点：

**前端请求**——>**node服务转发**——>**跳板机**——>**Nginx转发**——>**后台Tomcat服务**——>**后台代码**

第一反应是会不会是因为Nginx的配置导致的，记得之前有一次上传文件也报413，就是因为文件大小是8M，超出了Nginx配置的上限导致的。

于是第一时间联系了ops，他们查看结果是：
client_max_body_size 5M;(请求体缓存区大小)
client_body_buffer_size 128k;(客户端请求体缓冲区大小)

所以没有问题，为了保险起见，client_max_body_size修改为20M，但是问题还存在，所以并不是Nginx配置的问题。

这是我的注意力赚到了Tomcat，Tomcat的server.xml中，maxPostSize参数会限制post请求报文体的最大值，继续麻烦ops，发现server.xml中并没有配置这个参数，查了一下，没有配置的时候，默认值是2M（2097152 (2 megabytes).），也没有问题。。。

emmmmmm。。。。

因为前后端分离，不太清楚前端的实现会不会限制post报文体大小，虽然我很自信后端代码不会有问题，但还是先用postman测试了后端，发现即使是1M的数据，也没得问题。

所以，结果很明显了，问题基本出现在前端请求、node服务转发、跳板机三个位置。

找了前端同学了解了一下，原来他们node服务使用Egg.js框架，而Egg的配置jsonLimit，会限制json报文体的大小，如果没有配置的话，默认为100k。

修改为5M以后，问题解决。

完美。