Chrome net:: Ошибка ERR_INCOMPLETE_CHUNKED_ENCODING
В течение последних двух месяцев я получаю следующую ошибку на консоли разработчика Chrome:
net::ERR_INCOMPLETE_CHUNKED_ENCODING
Симптомы:
- Страницы не загружаются.
- Усеченные файлы CSS и JS.
- Висячие страницы.
Серверная среда:
Это происходит со мной на нашем внутреннем сервере Apache. Это не происходит ни с кем другим - т.е. Ни один из наших пользователей не сталкивается с этой проблемой - и никто не будет в нашей команде разработчиков.
Другие люди получают доступ к тому же самому серверу с той же самой версией Chrome. Я также попытался отключить все расширения и просмотр в режиме инкогнито - без эффекта.
Я использовал Firefox и то же самое происходит. Усеченные файлы и многое другое. Единственное, что Firefox не вызывает никаких консольных ошибок, поэтому вам нужно проверить HTTP-запрос через Firebug, чтобы увидеть проблему.
Заголовок ответа от 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
Во время тестирования я смог исправить проблему, запустив HTTP 1.0 в файле htaccess:
SetEnv downgrade-1.0
Это избавится от проблемы. Однако принудительное HTTP 1.0 через HTTP 1.1 не является правильным решением.
Обновить. Поскольку я единственный, кто испытывает эту проблему, я решил, что мне нужно потратить больше времени на изучение того, была ли проблема с клиентской стороной. Если я перейду в настройки Chrome и воспользуюсь опцией "Восстановить по умолчанию", проблема исчезнет в течение 10-20 минут. Затем он возвращается.
Ответы
Ответ 1
OK. Я проверил это в три раза, и я уверен на 100%, что он вызван моим антивирусом (ESET NOD32 ANTIVIRUS 5).
Всякий раз, когда я отключу защиту в реальном времени, проблема исчезает. Сегодня я оставил защиту в режиме реального времени в течение 6-7 часов, и проблема не возникала.
Несколько мгновений назад я снова включил его, только чтобы проблема возникла в течение минуты.
В течение последних 24 часов я включил и снова включил защиту в реальном времени, чтобы быть уверенным. Каждый раз - результат был тот же.
Обновление: я столкнулся с другим разработчиком, у которого была такая же проблема с защитой в реальном времени от его антивируса Касперского. Он отключил его, и проблема исчезла. Т.е. эта проблема не ограничивается ESET.
Ответ 2
Ошибка пытается сказать, что 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).
ОБНОВЛЕНИЕ: Я смог повторить эту ошибку (наконец-то), когда возникла фатальная ошибка, когда PHP (на том же локальном хосте) был буферизировать выходные данные. Я думаю, что вывод был слишком плохо искажен, чтобы быть полезным (заголовки, но мало или нет контента).
В частности, мой код рекурсивно вызывал сам себя, пока PHP, по праву, не сдался. Таким образом, сервер не отправил порцию терминала длиной 0 - что было проблемой, которую я идентифицировал ранее.
Ответ 3
У меня была эта проблема. Отследил его, попробовав большинство других ответов на этот вопрос. Это было вызвано владельцем и правами /var/lib/nginx
и, более конкретно, директорией /var/lib/nginx/tmp
, некорректной.
Каталог tmp используется fast-cgi для ответов на кеширование по мере их создания, но только если они превышают определенный размер. Таким образом, проблема прерывистая и возникает только тогда, когда сгенерированный отклик большой.
Проверьте nginx <host_name>.error_log
, чтобы узнать, есть ли у вас проблемы с правами.
Чтобы исправить, убедитесь, что владелец и группа /var/lib/nginx
, а все поддиреторы - nginx.
Ответ 4
Следующее должно исправить это для каждого клиента.
//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
Ответ 5
OMG, у меня была та же проблема 5 минут назад. Я нашел несколько часов, чтобы найти решение. На первый взгляд, отключение антивирусной проблемы в Windows. Но потом я заметил проблему на другом Linux-компьютере без антивируса. Ошибок в журналах nginx нет. Мой uwsgi
показал что-то о "Broken pipe", но не во всех запросах.
Знаешь что? На устройстве не осталось места, которое я обнаружил при перезапуске сервера в журнале базы данных, и df
одобрил это. Только объяснение о том, почему антивирус был решен, заключается в том, что он предотвращает кеширование браузера (он должен проверять каждый запрос), но браузер с каким-то странным поведением может просто игнорировать плохой ответ и отображать кэшированные ответы.
Ответ 6
Известна проблема Chrome. Согласно хромовым трекам Chrome и Chromium, для этого нет универсального решения. Эта проблема не связана с типом сервера и версией, это правильно в Chrome.
Настройка заголовка Content-Encoding
на identity
решила эту проблему для меня.
из developer.mozilla.org
идентичность | Указывает функцию идентификации (то есть без сжатия, модификация).
Итак, я могу предположить, что в некоторых случаях Chrome не может правильно выполнить gzip-компресс.
Ответ 7
В моем случае я имел /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)
, что, вероятно, приводило к ошибке Chrome net:: ERR_INCOMPLETE_CHUNKED_ENCODING.
Мне пришлось удалить /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
Ответ 8
Здесь проблема была в моем Avast AV.
Как только я отключил его, проблема исчезла.
Но я действительно хотел бы понять причину такого поведения.
Ответ 9
Я просто смотрел на аналогичную проблему. И заметил, что это произошло только тогда, когда на странице содержались символы UTF-8 с порядковым значением больше 255 (т.е. Многобайтом).
В итоге проблема заключалась в том, как вычислялся заголовок Content-Length. Основным бэкэнд был вычисление длины символа, а не длины байта. Отключение заголовков контентной длины исправляло проблему временно, пока я не смог исправить систему шаблонов заднего конца.
Ответ 10
Это происходило на серверах двух разных клиентов, разделенных на несколько лет, используя тот же код, который был развернут на сотнях других серверов за это время без проблем.
Для этих клиентов это происходило в основном на скриптах PHP, которые имели потоковый HTML-код, то есть страницы "Соединение: закрыть", где вывод был отправлен в браузер по мере того, как выход стал доступен.
Оказалось, что связь между процессом PHP и веб-сервером преждевременно снижалась до завершения script и до того, как истечет время ожидания.
Проблема заключалась в том, что opcache.fast_shutdown = 1 в основном файле php.ini. По умолчанию эта директива отключена, но, похоже, некоторые администраторы серверов считают, что здесь есть повышение производительности. Во всех моих тестах я никогда не замечал положительной разницы, используя эту настройку. По моему опыту, это привело к тому, что некоторые сценарии фактически выполнялись медленнее и имеют ужасную запись о том, что иногда происходит остановка, а script все еще выполняется или даже в конце выполнения, пока веб-сервер все еще читает с буфер. Существует старый отчет об ошибке с 2013 года, который не был решен по состоянию на февраль 2017 года, который может быть связан: https://github.com/zendtech/ZendOptimizerPlus/issues/146
Я видел следующие ошибки из-за этого
ERR_INCOMPLETE_CHUNKED_ENCODING
ERR_SPDY_PROTOCOL_ERROR
Иногда регистрируются коррелятивные segfaults; иногда нет.
Если у вас есть один, проверьте ваш phpinfo и убедитесь, что opcache.fast_shutdown отключен.
Ответ 11
Самое простое решение - увеличить proxy_read_timeout для вашего заданного местоположения прокси до более высокого значения (скажем, 120 с) в вашем nginx.conf.
location / {
....
proxy_read_timeout 120s
....
}
Я нашел это решение здесь https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/
Ответ 12
Мне жаль, что у меня нет точного ответа. Но я столкнулся с этой проблемой, и, по крайней мере, в моем случае, нашел способ обойти это. Поэтому, возможно, он предложит некоторые подсказки кому-то, кто знает больше о Php под капотом.
В сценарии есть массив, переданный функции. Содержимое этого массива используется для создания строки HTML, которая должна быть отправлена обратно в браузер, путем размещения ее внутри глобальной переменной, которая позже была напечатана. (Эта функция фактически ничего не возвращает. Sloppy, я знаю, но это не так.) Внутри этого массива, среди прочего, есть пара элементов, несущих по ссылке вложенные ассоциативные массивы, которые были определены вне этой функции, В результате процесса устранения я обнаружил, что манипуляция любым элементом внутри этого массива внутри этой функции, на которую ссылается или нет, включая попытку отмены этих ссылочных элементов, приводит к тому, что Chrome бросает ошибку net:: ERR_INCOMPLETE_CHUNKED_ENCODING и не отображает содержимое. Это несмотря на то, что строка HTML в глобальной переменной - именно то, что должно быть.
Только путем переустановки script, чтобы не применять ссылки на элементы массива, в первую очередь все снова начиналось нормально работать. Я подозреваю, что на самом деле это ошибка Php, связанная с наличием ссылочных элементов, отбрасывающих заголовки содержимого, но я действительно недостаточно знаю об этом, чтобы сказать наверняка.
Ответ 13
У меня была эта проблема с сайтом в Chrome и Firefox. Если бы я отключил Avast Web Shield, он ушел. Кажется, мне удалось заставить его работать с Web Shield, добавив некоторые htaccess htac5 htaccess в мой файл htaccess:
# ------------------------------------------------------------------------------
# | 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>
Ответ 14
Я просто хотел поделиться своим опытом с вами, если у кого-то может быть такая же проблема с MOODLE.
Наша платформа moodle была внезапно очень медленной, приборная панель занимала в 2-3 раза больше времени (до 6 секунд), чем обычно, и время от времени некоторые страницы вообще не загружались (не ошибка 404, но пустая страница). В консоли разработчика инструменты были видны следующие ошибки: net::ERR_INCOMPLETE_CHUNKED_ENCODING.
Поиск этой ошибки, похоже, проблема Chrome, но у нас была проблема с различными браузерами. После нескольких часов исследований и сравнения баз данных за несколько дней до того, как я, наконец, нашел проблему, кто-то включил мониторинг событий. Однако в журнале "Изменения конфигурации" это изменение не было видно! Отключение мониторинга событий, наконец, решило проблему - у нас не было правил, определенных для мониторинга событий.
Мы запускаем Moodle 3.1.2+ с MariaDB и PHP 5.4.
Ответ 15
Мое исправление:
<?php ob_start(); ?>
<!DOCTYPE html>
<html lang="de">
.....
....//your whole code
....
</html>
<?php
ob_clean();
ob_end_flush();
ob_flush();
?>
Надеюсь, что это поможет кому-то в будущем, и в моем случае проблема с Kaspersky, но исправление выше отлично работает.
Ответ 16
Я получал net::ERR_INCOMPLETE_CHUNKED_ENCODING
, при более внимательном изучении журналов ошибок сервера я обнаружил, что это произошло из-за тайм-аута выполнения сценария PHP.
Добавление этой строки поверх PHP-скрипта решило это для меня:
ini_set('max_execution_time', 300); //300 seconds = 5 minutes
Ссылка: Фатальная ошибка: превышено максимальное время выполнения 30 секунд
Ответ 17
В моем случае это происходило во время json-сериализации возвращаемой полезной нагрузки веб-api - у меня была "круговая" ссылка в моей модели Entity Framework, я возвращал простой граф объектов один-ко-многим, но у ребенка был ссылаясь на родителя, который, по-видимому, сериализатор json не нравится. Удаление свойства на дочернем объекте, который ссылался на родителя, сделал трюк.
Надеюсь, это поможет кому-то, у кого может быть аналогичная проблема.
Ответ 18
Когда я столкнулся с этой ошибкой (во время вызова AJAX из javascript); причина в том, что ответ от контроллера был ошибочным; он возвращал JSON, который был не в правильном формате.
Ответ 19
Ну. Недавно я тоже встретил этот вопрос. И, наконец, я получаю решения, которые действительно решают эту проблему.
Моей проблемой являются также страницы, которые не загружаются, и найти json-данные были случайным образом усечены.
Вот решения, которые я мог бы помочь решить эту проблему
1.Kill the anti-virus software process
2.Close chrome 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
Ответ 20
Если есть какой-либо цикл или элемент, который не существует, вы сталкиваетесь с этой проблемой.
При запуске приложения в Chrome страница пустая и перестает отвечать.
Начало сценария:
Окружение среды: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,
в ${myObj.getfName()}
Окончание сценария:
Причина проблемы: функция getfName() не определена на myObj.
Надеюсь, он вам поможет.
Ответ 21
Мое предположение, что сервер неправильно обрабатывает кодирование с передачей пакетов. Для завершения работы над файлом с терминальным блоком необходимо подключить фрагментированные файлы, чтобы указать, что весь файл был передан. Так что код ниже может работать:
echo "\n";
flush();
ob_flush();
exit(0);
Ответ 22
В моем случае было повреждено config для расширения mysqlnd_ms php на сервере. Забавно, что он работал нормально на запросах с небольшой продолжительностью. В журнале ошибок сервера было предупреждение, поэтому мы быстро его исправили.
Ответ 23
Это похоже на общую проблему с несколькими причинами и решениями, поэтому я собираюсь поставить свой ответ здесь для всех, кто может это потребовать.
Я получал net::ERR_INCOMPLETE_CHUNKED_ENCODING
в комбинации Chrome, osx, php70, httpd24, но тот же код работал нормально на рабочем сервере.
Я изначально очертил регулярные журналы, но ничего не появилось. Быстрый 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
A brew uninstall php70-mongodb
и a httpd -k restart
позже, и все было плавным.
Ответ 24
В моем случае это была проблема с html. В ответ json возникла ошибка "\n", вызвавшая проблему. Поэтому я удалил это.
Ответ 25
Увлекательно видеть, как много разных причин для этой проблемы!
Многие говорят, что это проблема Chrome, поэтому я попробовал Safari и все еще имел проблемы. Затем попробовал все решения в этом потоке, в том числе отключить мою AVG Realtime Protection, не повезло.
Для меня проблема была в моем файле .htaccess
. Все это содержало FallbackResource index.php
, но когда я переименовал его в htaccess.txt
, моя проблема была решена.
Ответ 26
Хм, я просто наткнулся на похожую проблему, но по другим причинам...
Я использую Laravel Valet в ванильном PHP-проекте с Laravel Mix. Когда я открыл сайт в Chrome, он net::ERR_INCOMPLETE_CHUNKED_ENCODING
ошибки net::ERR_INCOMPLETE_CHUNKED_ENCODING
. (Если сайт загружался по протоколу HTTPS, ошибка изменилась на net::ERR_SPDY_PROTOCOL_ERROR
.)
Я проверил php.ini
и opcache
не был включен. Я обнаружил, что в моем случае проблема была связана с управлением версиями файлов ресурсов - по какой-то причине она не похожа на строку запроса в URL-адресе ресурсов (ну, как ни странно, только один в частности?).
Я удалил mix.version()
для локальной среды, и сайт отлично загружается в моем Chrome по протоколам HTTP и HTTPS.
Ответ 27
В контексте Контроллера в 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.
Ответ 28
У меня была эта проблема (показывающая ERR_INCOMPLETE_CHUNKED_ENCODING в Chrome, ничего в других браузерах). Оказалось, проблема заключалась в том, что мой хостинг-провайдер GoDaddy добавил скрипт мониторинга в конце моего вывода.
https://www.godaddy.com/community/cPanel-Hosting/how-to-remove-additional-quot-monitoring-quot-script-added/td-p/62592
Ответ 29
Проверьте разрешение папки nginx и установите для этого разрешение appache:
chown -R www-data:www-data /var/lib/nginx
Ответ 30
Я решил ту же проблему, отключив плагин истечения срока действия заголовка в далеком будущем,
Hosting: Hostgator Wordpress Hosting