記一次異常: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

學習文章。。。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM