Chromeネット:: ERR_INCOMPLETE_CHUNKED_ENCODINGエラー
過去2か月間、Chromeの開発者コンソールで次のようなエラーが表示されました。
net::ERR_INCOMPLETE_CHUNKED_ENCODING
症状：
- ページが読み込まれていません。
- 切り捨てられたCSSおよびJSファイル.
- ページがぶら下がっています。
サーバー環境
- Apache 2.2.22
- PHP
- ウブンツ
これは私たちの社内Apacheサーバーで起こっています。それは他の誰にも起こっていません - すなわち私達のユーザーのどれもこの問題を経験していません - また他の誰も私達の開発チームにいません。
他のユーザーがまったく同じバージョンのChromeでまったく同じサーバーにアクセスしています。また、すべての拡張機能を無効にし、シークレットモードでブラウズしてみました - 効果はありません。
私はFirefoxを使用しましたが、まったく同じことが起こっています。切り捨てられたファイルなど唯一のことは、Firefoxはコンソールエラーを発生させないので、あなたは問題を見るためにFirebugを通してHTTPリクエストを調べる必要があります。
Apacheからの応答ヘッダ：
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:close
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Mon, 27 Apr 2015 10:52:52 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Pragma:no-cache
Server:Apache/2.2.22 (Ubuntu)
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.10-1ubuntu3.8
テスト中、私はhtaccessファイルにHTTP 1.0を強制することで問題を解決することができました。
SetEnv downgrade-1.0
これで問題は解決します。ただし、HTTP 1.0よりもHTTP 1.0を強制することは適切な解決策ではありません。
更新：この問題が発生しているのは私だけなので、クライアント側の問題かどうかを調査するにはもっと時間が必要だと考えました。 Chromeの設定にアクセスして[デフォルトに戻す]オプションを使用すると、問題は消えます約10-20分の間。それから戻ります。
OK。私はこれをトリプルテストしました、そして私は100％確信していますそれは私のアンチウイルスによって引き起こされていると思います（ESET NOD32 ANTIVIRUS 5）.
リアルタイム保護を無効にするたびに、問題は消えます。今日、私は6〜7時間リアルタイム保護をオフのままにしました、そして問題は決して起こりませんでした。
ほんの少し前に、私は問題が1分以内に表面化するためにだけそれを再びスイッチを入れました。
過去24時間の間に、念のためにリアルタイム保護を再びオン/オフにしました。毎回 - 結果は同じです。
更新日：私は彼のカスペルスキーアンチウイルスのリアルタイム保護とまったく同じ問題を抱えていた別の開発者に出会いました。彼はそれを無効にして問題は解決しました。すなわち、この問題はESETに限定されないようです。
エラーは、ページが送信されている間にChromeが切断されたことを言っています。あなたの問題はその理由を理解しようとしています。
どうやら、これはChromeのいくつかのバージョンに影響を与える既知の問題かもしれません。私が言える限りでは、これらのバージョンが送信されているチャンクのコンテンツの長さとそのチャンクの表現されたサイズに非常に敏感であるという問題です（私はそれにはほど遠いかもしれません）。要するに、わずかに不完全なヘッダの問題です。
一方、サーバーが端末の0レングスチャンクを送信していない可能性があります。これはob_flush();で修正可能かもしれません。 Chrome（または接続など）が遅くなっている可能性もあります。そのため、接続が閉じられたとき、ページはまだロードされていません。なぜこれが起こるのか私にはわかりません。
これは妄想プログラマーの答えです。
<?php
// ... your code
flush();
ob_flush();
sleep(2);
exit(0);
?>
あなたの場合は、スクリプトがタイムアウトした可能性があります。それがなぜあなただけに影響を与えるべきなのか私にはよくわかりませんが、それは多くの競合状態になる可能性がありますか？それは全くの推測です。スクリプトの実行時間を延ばすことでこれをテストできるはずです。
<?php
// ... your while code
set_time_limit(30);
// ... more while code
?>
Chromeのインストールを更新する必要があるのと同じくらい簡単かもしれません（この問題はChrome固有のものです）。
- https://code.google.com/p/chromium/issues/detail?id=461213
- IISとChrome：リソースの読み込みに失敗しました：net :: ERR_INCOMPLETE_CHUNKED_ENCODING
- https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding
UPDATE：PHP（同じローカルホスト上）が の間に致命的なエラーがスローされたとき、このエラーを（ついには）再現できました）出力バッファリング 出力があまりにもひどく悪用されてあまり役に立ちませんでした（ヘッダーだが内容がほとんどないかまったくない）。
具体的には、私が誤って自分のコードを自分自身を再帰的に呼び出して、PHPが正しく放棄されるまで繰り返しました。したがって、サーバーは端末の0長のチャンクを送信しませんでした - これは私が以前に確認した問題です。
私はこの問題を抱えていました。この質問に他のほとんどの答えを試した後それを追跡した。これは、/var/lib/nginxの所有者および権限、より具体的には/var/lib/nginx/tmpディレクトリが正しくないことが原因でした。
Tmpディレクトリは、レスポンスが生成されたときにレスポンスをキャッシュするためにfast-cgiによって使用されます。したがって、この問題は断続的であり、生成された応答が大きい場合にのみ発生します。
パーミッションの問題があるかどうかnginx <Host_name>.error_logを確認してください。
修正するには、/var/lib/nginxおよびすべてのサブディレクトリの所有者とグループがnginxであることを確認してください。
以下はすべてのクライアントに対してそれを修正するはずです。
//Gather output (if it is not already in a variable, use ob_start() and ob_get_clean() )
// Before sending output:
header('Content-length: ' . strlen($output));
しかし、私の場合は以下の方が良い選択肢であり、それを修正しました。
.htaccess：
php_value opcache.enable 0
OMG、私は5分前に同じ問題を抱えていました。私は解決策を見つけるために数時間を費やしました。一目でウイルス対策を無効にすると、Windows上の問題を解決しました。しかし、その後、私はウイルス対策なしで他のLinux PC上の問題に気づいた。 nginxログにエラーはありません。私のuwsgiは "Broken pipe"について何かを示しましたが、すべての要求についてではありませんでした。何がわかりますか？データベースログでサーバーを再起動したときに見つけたデバイスの空き容量がなく、dfがこれを承認しました。なぜアンチウイルスが解決されたのかについての唯一の説明はブラウザのキャッシュを妨げるということです（すべてのリクエストをチェックすべきです）が、奇妙な振る舞いをするブラウザは単に悪いレスポンスを無視しキャッシュされたレスポンスを表示できます。
Chromeの問題として知られています。 ChromeとChromiumのバグトラッカーによると、これに対する普遍的な解決策はありません。この問題はサーバーの種類やバージョンとは関係ありません。Chromeにあります。
Content-Encodingヘッダーをidentityに設定することでこの問題は解決しました。
アイデンティティ識別関数を示します（つまり、圧縮も修正もしません）。
だから、私は示唆することができる、場合によってはChromeは正しくgzip圧縮を実行できない。
私の場合、私はおそらくChrome net :: ERR_INCOMPLETE_CHUNKED_ENCODINGエラーの原因である/usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)を持っていました。
/usr/local/var/run/nginx/を削除して、nginxにもう一度作成させる必要がありました。
$ Sudo rm -rf /usr/local/var/run/nginx/
$ Sudo nginx -s stop
$ Sudo mkdir /usr/local/var/run/nginx/
$ Sudo chown nobody:nobody /usr/local/var/run/nginx/
$ Sudo nginx
これは、数年間離れた2つの異なるクライアントのサーバーで発生していました。その間、他の何百ものサーバーに問題なくデプロイされたコードと同じコードを使用していました。
これらのクライアントにとっては、ストリーミングHTMLを持つPHPスクリプト、つまり出力が利用可能になったときに出力がブラウザに送信された "Connection：close"ページで主に起こりました。
PHPプロセスとWebサーバーとの間の接続は、スクリプトが完了する前、およびタイムアウトする前に、途中で途絶えていました。
問題はメインのphp.iniファイルのopcache.fast_shutdown = 1でした。このディレクティブはデフォルトで無効になっていますが、ここでパフォーマンスを向上させることがあると考えるサーバー管理者もいます。私のすべてのテストで、この設定を使用したときに前向きな違いが見られたことは一度もありません。私の経験では、実際にはスクリプトの実行が遅くなり、スクリプトの実行中、またはWebサーバーがバッファからの読み取り中に実行が終了したときにshutdownに入るというひどい実績があります。関連する可能性がある、2013年2月現在未解決の2013年からの古いバグレポートがあります。 https://github.com/zendtech/ZendOptimizerPlus/issues/146
このERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERRORによって、次のようなエラーが表示されることがあります。時にはそうではありません。
どちらか一方が発生した場合は、phpinfoを確認し、opcache.fast_shutdownが無効になっていることを確認してください。
最も簡単な解決策は、設定したプロキシの場所のproxy_read_timeoutをnginx.confでより高い値（120など）に増やすことです。
location / {
....
proxy_read_timeout 120s
....
}
ここでこの解決策を見つけました https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/
ここで問題は私のAvast AVでした。無効にするとすぐに問題は解決しました。
しかし、私は本当にこの動作の原因を理解したいと思います。
私はちょうど同じような問題を抱えているのをじっと見つめた。そしてそれが気付いたのは、ページが255より大きい序数値（すなわちマルチバイト）を持つUTF-8文字を含んでいたときだけです。
問題になったのは、Content-Lengthヘッダーの計算方法です。基礎となるバックエンドは、バイト長ではなく文字長を計算していました。私がバックエンドのテンプレートシステムを修正することができるまで、コンテンツ長のヘッダをオフにすることは一時的に問題を修正しました。
私の場合は、Web APIリターンペイロードのJSONシリアル化中に発生していました。EntityFrameworkモデルに「循環」参照があり、単純な1対多のオブジェクトグラフが返されていましたが、子には参照が返されました。親、どうやらJSONシリアライザは好きではありません。親を参照していた子のプロパティを削除すると、うまくいきます。
これが似たような問題を抱えている人に役立つことを願っています。
私はChromeとFirefoxのサイトでこの問題を抱えていました。 Avast Web Shieldをオフにした場合は消えました。私のhtaccessファイルにhtml5ボイラープレートhtaccessのいくつかを追加することで、Web Shieldを動作させることができたようです。
# ------------------------------------------------------------------------------
# | Expires headers (for better cache control) |
# ------------------------------------------------------------------------------
# The following expires headers are set pretty far in the future. If you don't
# control versioning with filename-based cache busting, consider lowering the
# cache time for resources like CSS and JS to something like 1 week.
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 1 month"
# CSS
ExpiresByType text/css "access plus 1 week"
# Data interchange
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
# Favicon (cannot be renamed!)
ExpiresByType image/x-icon "access plus 1 week"
# HTML components (HTCs)
ExpiresByType text/x-component "access plus 1 month"
# HTML
ExpiresByType text/html "access plus 0 seconds"
# JavaScript
ExpiresByType application/javascript "access plus 1 week"
# Manifest files
ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds"
ExpiresByType text/cache-manifest "access plus 0 seconds"
# Media
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
# Web feeds
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType application/rss+xml "access plus 1 hour"
# Web fonts
ExpiresByType application/font-woff "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
</IfModule>
# ------------------------------------------------------------------------------
# | Compression |
# ------------------------------------------------------------------------------
<IfModule mod_deflate.c>
# Force compression for mangled headers.
# http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
</IfModule>
</IfModule>
# Compress all output labeled with one of the following MIME-types
# (for Apache versions below 2.3.7, you don't need to enable `mod_filter`
# and can remove the `<IfModule mod_filter.c>` and `</IfModule>` lines
# as `AddOutputFilterByType` is still in the core directives).
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE application/atom+xml \
application/javascript \
application/json \
application/rss+xml \
application/vnd.ms-fontobject \
application/x-font-ttf \
application/x-web-app-manifest+json \
application/xhtml+xml \
application/xml \
font/opentype \
image/svg+xml \
image/x-icon \
text/css \
text/html \
text/plain \
text/x-component \
text/xml
</IfModule>
</IfModule>
# ------------------------------------------------------------------------------
# | Persistent connections |
# ------------------------------------------------------------------------------
# Allow multiple requests to be sent over the same TCP connection:
# http://httpd.Apache.org/docs/current/en/mod/core.html#keepalive.
# Enable if you serve a lot of static content but, be aware of the
# possible disadvantages!
<IfModule mod_headers.c>
Header set Connection Keep-Alive
</IfModule>
申し訳ありませんが、正確な回答はありません。しかし、私はこの問題にも遭遇し、少なくとも私の場合はそれを回避する方法を見つけました。だから多分それはフードの下でPhpについてもっと知っている誰かにいくつかの手がかりを提供するでしょう。
シナリオは、関数に配列を渡したことです。この配列の内容は、後で印刷されるグローバル変数の中にすべて配置することによって、ブラウザに返送するHTML文字列を生成するために使用されています。この配列の中には、とりわけ、この関数の外側で定義された入れ子になった連想配列を持つ要素がいくつかあります。 。消去処理によって、この関数内でこの配列内の要素を操作した場合（参照されているかどうかにかかわらず）、Chromeでnet :: ERR_INCOMPLETE_CHUNKED_ENCODINGエラーが発生し、コンテンツが表示されないことがわかりました。これは、グローバル変数のHTML文字列がまさにそれがあるべきものであるという事実にもかかわらずです。
そもそも配列要素への参照を適用しないようにスクリプトを作り直すことによってのみ、正常に動作し始めました。これは実際にはPhpのバグで、参照されている要素がコンテンツ長のヘッダを投げ捨てることに関係しているのではないかと思いますが、これについては確かに十分にはわかりません。
誰かがMOODLEと同じ問題を抱えているのであれば、私はあなたと私の経験を共有したいと思いました。
私たちのMoodleプラットフォームは突然とても遅く、ダッシュボードのロードに通常よりも2〜3倍長く（最大6秒）かかり、時々何ページもロードされなかった（404エラーではなく空白ページ） ）開発者ツールコンソールで、次のエラーが表示されました。net::ERR_INCOMPLETE_CHUNKED_ENCODING.
このエラーを検索すると、Chromeが問題のようですが、さまざまなブラウザで問題が発生しています。私がようやく問題を発見する前の数日間の調査とデータベースの比較の後、誰かがEvent Monitoringをオンにしました。しかし、 "Config changes"ログでは、この変更は見えませんでした。 Event Monitoringをオフにすると、ようやく問題が解決しました - Event Monitoringにはルールが定義されていませんでした。
MariaDBとPHP 5.4を使用してMoodle 3.1.2以降を実行しています。
このエラーに直面したとき（javascriptからAJAX呼び出しを行っている間）;理由は、コントローラーからの応答が誤っていたためです。有効な形式ではないJSONを返していました。
私の修正は：
<?php ob_start(); ?>
<!DOCTYPE html>
<html lang="de">
.....
....//your whole code
....
</html>
<?php
ob_clean();
ob_end_flush();
ob_flush();
?>
これが将来誰かに役立つことを願っています、そして私の場合はKasperskyの問題ですが、上記の修正がうまくいくことを期待しています:)
これは複数の原因と解決策に共通の問題のように思えるので、私はそれを必要とするかもしれない人のために私の答えをここに置くつもりです。
Chrome、osx、php70、httpd24の組み合わせでnet::ERR_INCOMPLETE_CHUNKED_ENCODINGを取得していましたが、本番サーバーでも同じコードが正常に実行されました。
最初は通常のログを記録しましたが、実際には何も表示されませんでした。簡単なls -laterはsystem.logが/var/logの中で最も最近触れられたファイルであることを示しました、そしてそれをテーリングすると私に
Saved crash report for httpd[99969] version 2.4.16 (805)
to /Library/Logs/DiagnosticReports/httpd.crash
に含まれるもの：
Process: httpd [99974]
Path: /usr/sbin/httpd
Identifier: httpd
Version: 2.4.16 (805)
Code Type: X86-64 (Native)
Parent Process: httpd [99245]
Responsible: httpd [99974]
User ID: 70
PlugIn Path: /usr/local/opt/php70-mongodb/mongodb.so
PlugIn Identifier: mongodb.so
brew uninstall php70-mongodbとhttpd -k restartとそれ以降はすべてスムーズなセーリングでした。
Nginxフォルダのアクセス権を確認し、それにapacheのアクセス権を設定します。
chown -R www-data:www-data /var/lib/nginx
うーむ私はちょうど同じような問題に出くわしましたが、背後にあるさまざまな理由で...
私はLaravel ValetをVanilla PHPプロジェクトでLaravel Mix Chromeでこのサイトを開くと、net::ERR_INCOMPLETE_CHUNKED_ENCODINGエラーが発生していました。 （サイトをHTTPSプロトコルでロードした場合、エラーはnet::ERR_SPDY_PROTOCOL_ERRORに変わりました。）
php.iniとopcacheが有効になっていないことを確認しました。私の場合、問題はアセットファイルのバージョン管理に関連していることがわかりました - 何らかの理由で、それはアセットのURL内のクエリ文字列を好むようには見えませんでした。
私はローカル環境のためのmix.version()を削除しました、そしてサイトはHTTPとHTTPSプロトコルの両方で私のChromeにちょうどうまくロードします。
私はこの問題を抱えていました（ChromeではERR_INCOMPLETE_CHUNKED_ENCODINGが表示されますが、他のブラウザでは表示されません）。問題は、私のホスティングプロバイダGoDaddyが出力の最後に監視スクリプトを追加していたことです。
存在しないループやアイテムがあると、この問題に直面します。
Chromeでアプリを実行すると、ページが空白になって応答しなくなります。
シナリオ開始：
開発環境：MAC、STS 3.7.3、tc Pivotalサーバー3.1、Spring MVC Web、
$ {myObj.getfName（）}に
シナリオ終了：
問題の原因：getfName（）関数がmyObjに定義されていません。
お役に立てば幸いです。
Drupal 8（Symfony Framework）のコントローラーのコンテキストでは、この解決策は私にとって役に立ちました。
$response = new Response($form_markup, 200, array(
'Cache-Control' => 'no-cache',
));
$content = $response->getContent();
$contentLength = strlen($content);
$response->headers->set('Content-Length', $contentLength);
return $response;
そうでなければ、応答ヘッダ 'Transfer-Encoding'は 'chunked'という値を得ました。これはChromeブラウザにとっては問題かもしれません。
この問題にはいくつもの異なる原因があるのを見るのは魅力的です。
多くの人がChromeの問題だと言っているので、私はSafariを試したがそれでも問題を抱えていた。それから私のAVGリアルタイム保護をオフにするなど、このスレッドですべての解決策を試してみました。
私にとっては、問題は私の.htaccessファイルでした。含まれているのはFallbackResource index.phpだけでしたが、名前をhtaccess.txtに変更したところ、問題は解決しました。
私の場合、それはhtmlの問題でした。問題の原因となっているjson応答に '\ n'がありました。それで私はそれを取り除きました。
そうですね。少し前まで私はこの質問にも会いました。そして最後に、私はこの問題に本当に対処する解決策を手に入れました。
私の問題の症状はまた、ページが読み込まれていないとJSONデータがランダムに切り捨てられていたことです。
これが、私が要約したこの問題の解決に役立つ解決策です。
1.Kill the anti-virus software process
2.Close chrome's Prerendering Instant pages feature
3.Try to close all the apps in your browser
4.Try to define your Content-Length header
<?php
header('Content-length: ' . strlen($output));
?>
5.Check your nginx fastcgi buffer is right
6.Check your nginx gzip is open
私の場合、それはサーバー上のmysqlnd_ms php拡張子の設定が壊れていました。面白いのは、それが短時間のリクエストでうまく機能していたということです。サーバーエラーログに警告があったので、すぐに修正しました。
これは通常、クライアント側のイベントの次に、クライアントがサーバーに大量の要求を送信したときに発生します。
これは通常、クライアント側での「悪い」プログラミングの兆候です。
テーブルのすべての行を更新していると想像してください。
悪い方法は、各行を更新する要求を送信することです（要求が完了するのを待たずにrafale内に多数の要求がある）。それを修正するには、別のリクエストを送信する前に、リクエストが完了していることを確認してください。
良い方法は、更新されたすべての行を含むリクエストを送信することです。 （1リクエスト）
そのため、最初に、クライアント側で何が起こっているのかを調べ、必要に応じてコードをリファクタリングします。
Wiresharkを使用して、リクエストで何が問題になっているのかを特定します。
私の推測では、サーバーはチャンク転送エンコードを正しく処理していません。ファイル全体が転送されたことを示すために、チャンクファイルをターミナルチャンクで終端処理する必要があります。
echo "\n";
flush();
ob_flush();
exit(0);
サーバエラーを詳しく調べると、PHPスクリプト実行タイムアウトが原因であることがわかったので、net::ERR_INCOMPLETE_CHUNKED_ENCODINGを取得していました。
この行をPHPスクリプトの上に追加することで解決しました。
ini_set('max_execution_time', 300); //300 seconds = 5 minutes