3

この問題は、コードを変更せずに数日前に始まったようで、ローカルの tomcat サーバーが応答を停止するだけでした。

メインのフィルター ブレークポイントがヒットせず、一部のリソースのみが読み込まれます。

失敗するものは、応答ヘッダーが重複しているようです。

Accept-Ranges:bytes
Accept-Ranges:bytes
Content-Disposition:inline;filename="online-framework.js"
Content-Disposition:inline;filename="online-framework.js"
Content-Encoding:gzip
Content-Encoding:gzip
Content-Range:bytes 0-42062/42063
Content-Range:bytes 0-42062/42063
Content-Type:application/javascript
Content-Type:application/javascript
Date:Tue, 19 Apr 2016 13:01:18 GMT
ETag:online-framework.js_42063_1461060446000
ETag:online-framework.js_42063_1461060446000
Expires:Tue, 26 Apr 2016 13:01:19 GMT
Expires:Tue, 26 Apr 2016 13:01:19 GMT
Last-Modified:Tue, 19 Apr 2016 10:07:26 GMT
Last-Modified:Tue, 19 Apr 2016 10:07:26 GMT
Server:Apache-Coyote/1.1
Server:Apache-Coyote/1.1
Transfer-Encoding:chunked
Transfer-Encoding:chunked
Vary:Accept-Encoding
Vary:Accept-Encoding

そして chrome は error:Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODINGで停止します。これは理にかなっています。

tomcat コネクタは変更されておらず、gzip 応答が含まれています。私は何を試しましたか：

  • スレッド ダンプ - 明確なブロック コードはありません
  • wireshark - 何がうまくいかないのかを理解するのに十分なほどよくわからない
  • ウイルス対策を無効にしました
  • プロキシが実行されていません

ページは永遠に読み込まれるようです。これがキッカーです。これはランダムに発生し、1 時間は機能し始めますが、次の時間は機能しません。

私が考えることができる唯一のことは、いくつかのドメインが変更された可能性があり、Windowsの更新が実行されておらず、他の3台または4台のPCが同じことを行い、他の2台はそうではないことです（同じビルド）

次にどこを見ればいいのかわからない？何か案は？

4

1 に答える 1

2

わかりました、ここで私自身の質問に答えますが、解決策を見つけました。

@BalusCによって作成されたカスタムファイル サーブレットを使用していました。問題はそこにあった

ここに私の発見があります：

  • Content-Encoding: gzipとを組み合わせて使用​​すると、この問題が発生します。Content-Range
  • 結果のエラーは次のとおりです。ERR_INCOMPLETE_CHUNKED_ENCODING
  • 私は最初にこのフィルターを無効にして、TomcatDefaultServletに処理させることにしました...問題は解決しました
  • プログラマーとして、私はその理由を知らなければなりませんでした。
  • 正確な理由はまだわかりませんが、gzip は長さで正確に表現できないためだと思います。

の仕様にContent-Rangeも次のように記載されています。

Content-Range エンティティ ヘッダーは、完全なエンティティ ボディのどこに部分ボディを適用するかを指定するために、部分エンティティ ボディとともに送信されます。範囲単位は、セクション 3.12 で定義されています。

コード内では、完全な応答であっても送信されました。

if (ranges.isEmpty() || ranges.get(0) == full) {
    // Return full file.
    Range r = full;
    response.setContentType(contentType);
    response.setHeader("Content-Range", "bytes " + r.start + "-" + r.end + "/" + r.total);

    if (content) {
        // .....

その行を削除すると、すべてが再び機能し始めました! 誰かがこれに参加して、おそらくより良い説明をしてくれることを本当に望んでいます.

chrome://net-internals/失敗したファイルの出力は次のとおりです。

t= 3740 [st= 38] -HTTP_STREAM_REQUEST
t= 3740 [st= 38] +HTTP_TRANSACTION_SEND_REQUEST [dt=0]
t= 3740 [st= 38] HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> GET /Core/resources/scripts/scriptaculous/dragdrop.js?t=1461139610 HTTP/1.1
                              ホスト: ローカルホスト:8080
                              接続: キープアライブ
                              プラグマ: no-cache
                              キャッシュ制御: キャッシュなし
                              承認： */*
                              ユーザーエージェント: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (Gecko のような KHTML) Chrome/49.0.2623.112 Safari/537.36
                              DNT: 1
                              リファラー: http://localhost:8080/Core/Dashboard?componentID=VCmq3c
                              Accept-Encoding: gzip、deflate、sdch
                              Accept-Language: en-US,en;q=0.8,af;q=0.6
                              Cookie: [306 バイトが取り除かれました]
t= 3740 [st= 38] -HTTP_TRANSACTION_SEND_REQUEST
t= 3740 [st= 38] +HTTP_TRANSACTION_READ_HEADERS [dt=4]
t= 3740 [st= 38] HTTP_STREAM_PARSER_READ_HEADERS [dt=4]
t= 3744 [st= 42] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                          --> HTTP/1.1 200 OK
                              サーバー: Apache-コヨーテ/1.1
                              Content-Disposition: inline;filename="dragdrop.js"
                              Accept-Ranges: バイト
                              ETag: dragdrop.js_19250_1461136271305
                              最終更新日: 2016 年 4 月 20 日 (水) 07:11:11 GMT
                              有効期限: 2016 年 4 月 27 日 (水) 08:06:51 GMT
                              コンテンツ範囲: バイト 0 ～ 19249/19250
                              コンテンツ タイプ: アプリケーション/JavaScript
                              Transfer-Encoding: チャンク
                              Vary: Accept-Encoding
                              日付: 2016 年 4 月 20 日 (水) 08:06:50 GMT
t= 3744 [st= 42] -HTTP_TRANSACTION_READ_HEADERS
t= 3744 [st= 42] HTTP_CACHE_WRITE_INFO [dt=56]
t= 3800 [st= 98] HTTP_CACHE_WRITE_DATA [dt=0]
t= 3800 [st= 98] HTTP_CACHE_WRITE_INFO [dt=1]
t= 3801 [st= 99] URL_REQUEST_DELEGATE [dt=0]
t= 3801 [st= 99] -URL_REQUEST_START_JOB
t= 3801 [st= 99] URL_REQUEST_DELEGATE [dt=0]
t= 3801 [st= 99] HTTP_TRANSACTION_READ_BODY [dt=0]
t= 3801 [st= 99] HTTP_CACHE_WRITE_DATA [dt=1]
t= 3802 [st= 100] URL_REQUEST_JOB_BYTES_READ
                      --> バイト数 = 3683
t= 3802 [st= 100] HTTP_TRANSACTION_READ_BODY [dt=0]
t= 3802 [st= 100] HTTP_CACHE_WRITE_DATA [dt=0]
t= 3802 [st= 100] URL_REQUEST_JOB_BYTES_READ
                      --> バイト数 = 13982
t= 3802 [st= 100] HTTP_TRANSACTION_READ_BODY [dt=20365]
                      --> net_error = -355 (ERR_INCOMPLETE_CHUNKED_ENCODING)
t=24167 [st=20465] 失敗
                      --> net_error = -355 (ERR_INCOMPLETE_CHUNKED_ENCODING)
t=24168 [st=20466] -REQUEST_ALIVE
                    --> net_error = -355 (ERR_INCOMPLETE_CHUNKED_ENCODING)

そして最後に、ここに私を本当に助けてくれたリンクがいくつかあります.春は昨年同じ問題を抱えていたようです.

何年も正常に実行された後、これがランダムに開始された理由をまだ理解できず、ご意見をいただければ幸いです。

于 2016-04-20T08:34:34.483 に答える