記一次異常：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的<Valve className="com*.session.redis.RedisSessionHandlerValve"/>配置。

這個類是公司的不便寫出來，可是基本內容是繼承了：

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裏

 <Manager name="applicationName" className="com.*.session.redis.RedisSessionManager">

那麼tomcat再執行這裏的時候，沒有這個對象理論上是執行不了或者有異常爆出來的，但tomcat沒有爆出異常，這個問題今天先到這兒，找時間本身寫個鉤子進去測試下。

要補一下tomcat的鉤子處理：

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

學習文章。。。