php Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING 错误

Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING error

提问by Wayne Whitty

For the past two months, I have been receiving the following error on Chrome's developer console:

在过去的两个月里，我一直在 Chrome 的开发者控制台上收到以下错误：

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Symptoms:

症状：

• Pages not loading.
• Truncated CSS and JS files.
• Pages hanging.

• 页面未加载。
• 截断的 CSS 和 JS 文件。
• 页面挂。

Server environment:

服务器环境：

• Apache 2.2.22
• PHP
• Ubuntu

• 阿帕奇 2.2.22
• PHP
• Ubuntu

This is happening to me on our in-house Apache server. It is not happening to anybody else - i.e. None of our users are experiencing this problem - nor is anybody else on our dev team.

这发生在我的内部 Apache 服务器上。它不会发生在其他任何人身上 - 即我们的用户都没有遇到这个问题 - 我们开发团队中的其他人也没有。

Other people are accessing the exact same server with the exact same version of Chrome. I have also tried disabling all extensions and browsing in Incognito mode - to no effect.

其他人正在使用完全相同版本的 Chrome 访问完全相同的服务器。我还尝试在隐身模式下禁用所有扩展程序和浏览 - 没有效果。

I have used Firefox and the exact same thing is occurring. Truncated files and whatnot. The only thing is, Firefox doesn't raise any console errors so you need to inspect the HTTP request via Firebug to see the problem.

我使用过 Firefox，并且发生了完全相同的事情。截断的文件等等。唯一的问题是，Firefox 不会引发任何控制台错误，因此您需要通过 Firebug 检查 HTTP 请求以查看问题。

Response Headers from Apache:

来自 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

While testing, I was able to fix the issue by forcing HTTP 1.0 in my htaccess file:

在测试时，我能够通过在我的 htaccess 文件中强制使用 HTTP 1.0 来解决这个问题：

SetEnv downgrade-1.0

This gets rid of the problem. However, forcing HTTP 1.0 over HTTP 1.1 is not a proper solution.

这摆脱了这个问题。但是，强制 HTTP 1.0 超过 HTTP 1.1 并不是一个合适的解决方案。

Update: Because I'm the only one experiencing this issue, I figured that I needed to spend more time investigating whether or not it was a client side issue. If I go into Chrome's settings and use the "Restore to Default" option, the problem will disappearfor about 10-20 minutes. Then it returns.

更新：因为我是唯一遇到此问题的人，所以我认为我需要花更多时间调查这是否是客户端问题。如果我进入 Chrome 的设置并使用“恢复为默认值”选项，问题将消失大约 10-20 分钟。然后它返回。

采纳答案by Wayne Whitty

OK. I've triple-tested this and I am 100% surethat it is being caused by my anti-virus (ESET NOD32 ANTIVIRUS 5).

好的。我已经对此进行了三次测试，我100% 确定它是由我的防病毒软件 (ESET NOD32 ANTIVIRUS 5) 引起的。

Whenever I disable the Real-Time protection, the issue disappears. Today, I left the Real-Time protection off for 6-7 hours and the issue never occurred.

每当我禁用实时保护时，问题就会消失。今天，我将实时保护关闭了 6-7 个小时，但问题从未发生。

A few moments ago, I switched it back on, only for the problem to surface within a minute.

几分钟前，我重新打开它，只是为了问题在一分钟内浮出水面。

Over the course of the last 24 hours, I have switched the Real-Time protection on and off again, just to be sure. Each time - the result has been the same.

在过去的 24 小时内，我再次打开和关闭实时保护，只是为了确定。每次 - 结果都是一样的。

Update: I have come across another developer who had the exact same problem with the Real-Time protection on his Kaspersky anti-virus. He disabled it and the problem went away. i.e. This issue doesn't seem to be limited to ESET.

更新：我遇到了另一位开发人员，他的卡巴斯基反病毒软件的实时保护存在完全相同的问题。他禁用了它，问题就消失了。即这个问题似乎不仅限于 ESET。

回答by Matthew Brown aka Lord Matt

The error is trying to say that Chrome was cut off while the page was being sent. Your issue is trying to figure out why.

该错误试图说明在发送页面时 Chrome 被切断了。您的问题是试图找出原因。

Apparently, this might be a known issue impacting a couple of versions of Chrome. As far as I can tell, it is an issue of these versions being massively sensitive to the content length of the chunk being sent and the expressed size of that chunk (I could be far off on that one). In short, a slightly imperfect headers issue.

显然，这可能是影响几个 Chrome 版本的已知问题。据我所知，这是一个问题，这些版本对发送的块的内容长度和该块的表示大小非常敏感（我可能离那个很远）。简而言之，一个稍微不完美的标题问题。

On the other hand, it could be that the server does not send the terminal 0-length chunk. Which might be fixable with ob_flush();. It is also possible that Chrome (or connection or something) is being slow. So when the connection is closed, the page is not yet loaded. I have no idea why this might happen.

另一方面，可能是服务器没有发送终端长度为 0 的块。这可能可以用ob_flush();. Chrome（或连接或其他东西）也可能很慢。所以当连接关闭时，页面还没有加载。我不知道为什么会发生这种情况。

Here is the paranoid programmers answer:

这是偏执程序员的答案：

<?php
    // ... your code
    flush();
    ob_flush();
    sleep(2);
    exit(0);
?>

In your case, it might be a case of the script timing out. I am not really sure why it should affect only you but it could be down to a bunch of race conditions? That's an utter guess. You should be able to test this by extending the script execution time.

在您的情况下，可能是脚本超时的情况。我不确定为什么它应该只影响你，但它可能归结为一堆竞争条件？这完全是猜测。您应该能够通过延长脚本执行时间来测试这一点。

<?php
    // ... your while code
    set_time_limit(30);
    // ... more while code
?>

It also may be as simple as you need to update your Chrome install (as this problem is Chrome specific).

它也可能像您需要更新 Chrome 安装一样简单（因为此问题是 Chrome 特有的）。

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS & Chrome: failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

• 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:I was able to replicate this error (at last) when a fatal error was thrown while PHP (on the same localhost) was output buffering. I imagine the output was too badly mangled to be of much use (headers but little or no content).

更新：当 PHP（在同一本地主机上）输出缓冲时抛出致命错误时，我能够复制此错误（最后）。我想输出被严重破坏而没有多大用处（标题但很少或没有内容）。

Specifically, I accidentally had my code recursively calling itself until PHP, rightly, gave up. Thus, the server did not send the terminal 0-length chunk - which was the problem I identified earlier.

具体来说，我不小心让我的代码递归调用自身，直到 PHP 正确地放弃。因此，服务器没有发送终端长度为 0 的块——这是我之前发现的问题。

回答by SimonAlfie

I had this issue. Tracked it down after trying most the other answers on this question. It was caused by the owner and permissions of the /var/lib/nginxand more specifically the /var/lib/nginx/tmpdirectory being incorrect.

我有这个问题。在尝试了有关此问题的大多数其他答案后对其进行了追踪。这是由目录的所有者和权限引起的/var/lib/nginx，更具体地说是/var/lib/nginx/tmp目录不正确。

The tmp directory is used by fast-cgi to cache responses as they are generated, but only if they are above a certain size. So the issue is intermittent and only occurs when the generated response is large.

fast-cgi 使用 tmp 目录在响应生成时缓存响应，但前提是它们超过特定大小。所以这个问题是间歇性的，只有在生成的响应很大时才会发生。

Check the nginx <host_name>.error_logto see if you are having permission issues.

检查nginx <host_name>.error_log以查看您是否遇到权限问题。

To fix, ensure the owner and group of /var/lib/nginxand all sub-dirs is nginx.

要修复，请确保/var/lib/nginx所有子目录的所有者和组是 nginx。

回答by twicejr

The following should fix it for every client.

以下应该为每个客户端修复它。

//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));

But in my case the following was a better option and fixed it as well:

但在我的情况下，以下是更好的选择并修复了它：

.htaccess:

.htaccess：

php_value opcache.enable 0

回答by Ivan Borshchov

OMG, I solved the same problem 5 minutes ago. I spent several hours to find a solution. At first sight disabling antivirus solved problem on Windows. But then I noticed issue on other linux pc with no antivirus. No errors in nginx logs. My uwsgishowed something about "Broken pipe" but not on all requests. Know what? It was no space left on device, which I found when restarted server on Database log, and dfapproved this. Only explanation about why antivirus was solved this is that it prevents browser caching (it should check every request), but browser with some strange behavior can simply ignore bad response and show cached responses.

天哪，我 5 分钟前解决了同样的问题。我花了几个小时才找到解决办法。乍一看，禁用防病毒解决了 Windows 上的问题。但是后来我注意到其他没有防病毒软件的 linux pc 上的问题。nginx 日志中没有错误。我uwsgi展示了一些关于“Broken pipe”的东西，但不是所有的请求。知道什么？设备上没有剩余空间，我在数据库日志上重新启动服务器时发现了df这一点，并批准了这一点。关于为什么防病毒解决这个问题的唯一解释是它阻止浏览器缓存（它应该检查每个请求），但是具有一些奇怪行为的浏览器可以简单地忽略错误响应并显示缓存响应。

回答by Pedro Casado

In my case i was having /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)which was probably resulting the Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING error.

在我的情况下，我/usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)可能会导致 Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING 错误。

I had to remove /usr/local/var/run/nginx/and let nginx create it again.

我不得不删除/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

回答by Mikhail Tulubaev

It is known Chrome problem. According to Chrome and Chromium bug trackers there is no universal solution for this. This problem is not related with server type and version, it is right in Chrome.

已知 Chrome 问题。根据 Chrome 和 Chromium 错误跟踪器的说法，对此没有通用的解决方案。此问题与服务器类型和版本无关，在 Chrome 中是正确的。

Setting Content-Encodingheader to identitysolved this problem to me.

设置Content-Encoding标题identity为我解决了这个问题。

from developer.mozilla.org

来自developer.mozilla.org

identity | Indicates the identity function (i.e. no compression, nor modification).

身份| 表示身份函数（即不压缩，也不修改）。

So, I can suggest, that in some cases Chrome can not perform gzip compress correctly.

所以，我可以建议，在某些情况下 Chrome 无法正确执行 gzip 压缩。

回答by Troy Morehouse

I just stared having a similar problem. And noticed it was only happening when the page contained UTF-8 characters with an ordinal value greater than 255 (i.e. multibyte).

我只是盯着有类似的问题。并注意到只有当页面包含序数值大于 255（即多字节）的 UTF-8 字符时才会发生这种情况。

What ended up being the problem was how the Content-Length header was being calculated. The underlying backend was computing character length, rather than byte length. Turning off content-length headers fixed the problem temporarily until I could fix the back end template system.

最终的问题是如何计算 Content-Length 标头。底层后端是计算字符长度，而不是字节长度。关闭内容长度标头暂时解决了这个问题，直到我可以修复后端模板系统。

回答by shailesh p

When i faced this error( while making AJAX call from javascript ); the reason was the response from controller was erroneous; it was returning a JSON which was not of valid format.

当我遇到此错误时（从 javascript 进行 AJAX 调用时）；原因是控制者的响应有误；它返回了一个无效格式的 JSON。

回答by Srinivas Pandranki

The easiest solution is to increase the proxy_read_timeout for your set proxy location to a higher value (let say 120s) in your nginx.conf.

最简单的解决方案是在 nginx.conf 中将设置的代理位置的 proxy_read_timeout 增加到更高的值（比如 120 秒）。

location / {
....
proxy_read_timeout 120s
....
}

I found this solution here https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

我在这里找到了这个解决方案 https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/