记一次异常：Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING

早上突然出现问题，tomcat部署的web服务，访问页面的时候报：Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING 这个异常，试了试其他浏览器正常，只有google的Chrome浏览器有问题，然后开始各种搜索这个问题的解决方案，有以下几种说法：

 

分析的比较好的文章是：https://bugs.chromium.org/p/chromium/issues/detail?id=461213

这是其中的一个答复，牵扯到html协议的内容，相当屌，先留下来，后边研究html协议的时候，可以拿过来当一个案例

This is typically caused by a server not sending us the terminal 0-length chunk.  
We sit around waiting for more data with the request hung until the server closes the socket.  
At that point, we have no way to know whether we've received the entire file or not.  This seems to be working as intended.  
The server needs to be fixed.

这个写的最靠谱，是浏览器或者返回的时候，不知道到底有没有获取完成，所以就爆了这个错，详细看下要。

 

1：第一种最多的是返回的json内容太长被截取了

这个部分就是怀疑后端代码有问题了，或者传输过程中有问题了，于是安装了Charles抓包工具，想抓一下json是否有问题，结果用了抓包工具之后，好了，不再报错了，

此刻已经有些崩溃了，不知道该怎么继续查了，但是可以排除是代码的问题了，因为代码返回到抓包工具里的json内容是正常的，没有问题。

 

2：开始的时候怀疑的前端有问题：https://github.com/vuejs-templates/webpack/issues/731

因为是用的vuejs，加上上午刚提交了vuejs的代码，怀疑可能是前端问题，搜索vuejs、ajax、post、net::ERR_INCOMPLETE_CHUNKED_ENCODING

这些出来的看上去靠点儿谱的答案就是上边的链接了，提到了

webpack-hot-middleware

组件，看上去挺像的，打包使用的组件，怀疑可能是打包出了问题，后来搜索了下自己的package.json里我压根没用过这个组件，排除了这个可能性。

 

3：还有一个http://thisinterestsme.com/err_incomplete_chunked_encoding/

这个搜索的出现量也是最多的，主要是说可能是浏览器设置的问题推荐了集中方法处理，但试了试并没有可行的方法，不过思路可能是对的，我就试着各种删除cookie、缓存，甚至重置了chrome浏览器，并没有卵用，就排除了浏览器问题的可能性

 

4：排除了代码上的问题的可能性，也排除了chrome的配置问题，最后开始排查运行坏境的问题了，自然想到容器tomcat

上边两个思路，一个是怀疑前端的问题，一个是怀疑后端的问题，这两个可能性都排除了，最后只能来怀疑tomcat容器了，因为公司的tomcat是公司做过改动的定制的模板生成的，所以可能会有一些个性的配置，加上自己的tomcat上运行的确实没问题，那么接下来就是排查了，down下来公司的tomcat，本地运行果然也是一样的问题，那么继续排查conf配置文件，最后定位是context.xml里的一个配置除了问题，是公司的一段redisSession的配置，想起来是我昨天不用然后注释掉的，但是没有注释完，偏偏留了一句

而这一句是正好是tomcat的配置。

这个类是公司的不便写出来，但是基本内容是继承了：

org.apache.catalina.valves.ValveBase

这个类，是tomcat的钩子，然后在钩子的invoke里做了些事情：

@Override
    public void invoke(Request request, Response response) throws IOException, ServletException {
        try {
            getNext().invoke(request, response);
        } finally {
            manager.afterRequest();
        }
    }

try里的语句看上去没问题，可疑的就是finally里的代码了，manager是公司的RedisSesssionManager，我昨天注释掉的就是这个类的实例，在tomcat里

 

那么tomcat再执行这里的时候，没有这个对象理论上是执行不了或者有异常爆出来的，但tomcat没有爆出异常，这个问题今天先到这儿，找时间自己写个钩子进去测试下。

要补一下tomcat的钩子处理：

http://dev.dafan.info/detail/305732?p=30-51-68

学习文章。。。

转载于:https://www.cnblogs.com/aquariusm/p/8352633.html