В течение последних двух месяцев я получал следующую ошибку на консоли разработчика Chrome:
net::ERR_INCOMPLETE_CHUNKED_ENCODING
Симптомы:
Серверная среда:
Это происходит со мной на нашем собственном сервере 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 минут. Затем он возвращается.
ОК. Я проверил это в три раза, и я на 100% уверен, что это вызвано моим антивирусом (ESET NOD32 ANTIVIRUS 5).
Всякий раз, когда я отключу защиту в реальном времени, проблема исчезает. Сегодня я оставил защиту в режиме реального времени в течение 6-7 часов, и проблема не возникала.
Несколько мгновений назад я снова включил его, только чтобы проблема возникла в течение минуты.
В течение последних 24 часов я снова включил защиту в реальном времени, чтобы быть уверенным. Каждый раз – результат был один и тот же.
Обновление: я столкнулся с другим разработчиком, у которого была такая же проблема с защитой в реальном времени от его антивируса Касперского. Он отключил его, и проблема исчезла. т.е. эта проблема не ограничивается ESET.
Ошибка пытается сказать, что Chrome был отключен во время отправки страницы. Ваша проблема пытается понять, почему.
По-видимому, это может быть известная проблема, затрагивающая пару версий Chrome. Насколько я могу судить, проблема в том, что эти версии очень чувствительны к длине содержимого отправляемого фрагмента и выраженному размеру этого фрагмента (я мог бы быть далеко от него). Короче говоря, немного несовершенный вопрос заголовков.
С другой стороны, может случиться так, что сервер не отправит терминал длиной 0 строк. Что может быть ob_flush();
с помощью 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).
UPDATE: я смог реплицировать эту ошибку (наконец), когда была вызвана фатальная ошибка, в то время как PHP (на том же локальном хосте) был обработан буферизацией . Я предполагаю, что результат слишком сильно искалечен, чтобы быть полезен (заголовки, но мало или вообще не содержались).
В частности, я случайно использовал свой код, рекурсивно называющий себя до тех пор, пока PHP, по правде говоря, не сдался. Таким образом, сервер не отправил терминал длиной 0 строк – это была проблема, которую я определил ранее.
Следующее должно исправить это для каждого клиента.
//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
У меня была эта проблема. Отследил его, попробовав большинство других ответов на этот вопрос. Это было вызвано владельцем и правами /var/lib/nginx
и, более конкретно, каталог /var/lib/nginx/tmp
некорректен.
Каталог tmp используется fast-cgi для ответов на кеширование по мере их создания, но только если они превышают определенный размер. Таким образом, проблема прерывистая и возникает только тогда, когда сгенерированный отклик большой.
Проверьте nginx <host_name>.error_log
чтобы узнать, есть ли у вас проблемы с разрешением.
Чтобы исправить, убедитесь, что владелец и группа /var/lib/nginx
и все субдиры – nginx.
OMG, у меня была такая же проблема 5 минут назад. Я нашел несколько часов, чтобы найти решение. На первый взгляд, отключение антивирусной проблемы в Windows. Но потом я заметил проблему на другом Linux-компьютере без антивируса. Ошибок в журналах nginx нет. Мой uwsgi
показал что-то о «Broken pipe», но не по всем запросам. Знаешь что? На устройстве не осталось места, которое я обнаружил при перезапуске сервера в журнале базы данных, и df
одобрил это. Только объяснение о том, почему антивирус был решен, заключается в том, что он предотвращает кеширование браузера (он должен проверять каждый запрос), но браузер с каким-то странным поведением может просто игнорировать плохой ответ и отображать кэшированные ответы.
Известна проблема Chrome. Согласно хромовым трекам Chrome и Chromium, для этого нет универсального решения. Эта проблема не связана с типом сервера и версией, это правильно в Chrome.
Настройка заголовка Content-Encoding
для identity
помогла мне решить эту проблему.
от разработчика.mozilla.org
идентичность | Указывает функцию идентификации (то есть без сжатия или изменения).
Поэтому я могу предположить, что в некоторых случаях Chrome не может выполнить gzip-компресс правильно.
Здесь проблема была в моем Avast AV. Как только я отключил его, проблема исчезла.
Но я действительно хотел бы понять причину такого поведения.
Я просто смотрел на аналогичную проблему. И заметил, что это произошло только тогда, когда на странице содержались символы UTF-8 с порядковым значением больше 255 (т. Е. Многобайтовым).
В результате проблема заключалась в том, как вычислялся заголовок Content-Length. Основным бэкэнд был вычисление длины символа, а не длины байта. Отключение заголовков контентной длины исправляло проблему временно, пока я не смог исправить систему шаблонов задних окон.
Мне жаль, что у меня нет точного ответа. Но я столкнулся с этой проблемой, и, по крайней мере, в моем случае, нашел способ обойти это. Так что, возможно, он предложит некоторые подсказки кому-то, кто знает больше о Php под капотом.
В сценарии есть массив, переданный функции. Содержимое этого массива используется для создания строки HTML, которая будет отправлена обратно в браузер, путем размещения ее внутри глобальной переменной, которая позже будет напечатана. (Эта функция фактически ничего не возвращает. Sloppy, я знаю, но это не относится к делу.) Внутри этого массива, среди прочего, есть пара элементов, несущих по ссылке вложенные ассоциативные массивы, которые были определены вне этой функции , В результате процесса устранения я обнаружил, что манипуляция любым элементом внутри этого массива внутри этой функции, на которую ссылается или нет, включая попытку отмены этих ссылочных элементов, приводит к тому, что Chrome бросает ошибку net :: ERR_INCOMPLETE_CHUNKED_ENCODING и не отображает содержимое. Это несмотря на то, что строка HTML в глобальной переменной – именно то, что должно быть.
Только путем переустановки сценария, чтобы не применять ссылки на элементы массива, в первую очередь все снова начиналось нормально работать. Я подозреваю, что на самом деле это ошибка Php, связанная с наличием ссылочных элементов, отбрасывающих заголовки содержимого, но я действительно недостаточно знаю об этом, чтобы сказать наверняка.
У меня была эта проблема с сайтом в 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>
В моем случае у меня был /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
Я просто хотел поделиться своим опытом с вами, если у кого-то может быть такая же проблема с MOODLE .
Наша платформа moodle была внезапно очень медленной, приборная панель заняла примерно 2-3 раза дольше, чтобы загрузить (до 6 секунд), чем обычно, и время от времени некоторые страницы вообще не загружались (не ошибка 404, а пустая страница ). В консоли разработчика были видны следующие ошибки: net::ERR_INCOMPLETE_CHUNKED_ENCODING.
Поиск этой ошибки, похоже, проблема Chrome, но у нас была проблема с различными браузерами. После нескольких часов исследований и сравнения баз данных за несколько дней до того, как я, наконец, нашел проблему, кто-то включил мониторинг событий. Однако в журнале «Изменения конфигурации» это изменение не было видно! Отключение мониторинга событий, наконец, решило проблему – у нас не было правил, определенных для мониторинга событий.
Мы запускаем Moodle 3.1.2+ с MariaDB и PHP 5.4.
Мое исправление:
<?php ob_start(); ?> <!DOCTYPE html> <html lang="de"> ..... ....//your whole code .... </html> <?php ob_clean(); ob_end_flush(); ob_flush(); ?>
Надеюсь, это поможет кому-то в будущем, и в моем случае проблема с Kaspersky, но исправление выше отлично работает 🙂
Это происходило на серверах двух разных клиентов, разделенных на несколько лет, используя тот же код, который был развернут на сотнях других серверов за это время без проблем.
Для этих клиентов это происходило, главным образом, на скриптах PHP, которые имели потоковый HTML – то есть, «Соединение: закрыть» страницы, где вывод был отправлен в браузер по мере того, как выход стал доступным.
Оказалось, что связь между процессом PHP и веб-сервером преждевременно снижалась, прежде чем скрипт завершился и прошел путь до любого таймаута.
Проблема заключалась в opcache.fast_shutdown = 1 в основном файле php.ini. По умолчанию эта директива отключена, но, похоже, некоторые администраторы серверов считают, что здесь есть повышение производительности. Во всех моих тестах я никогда не замечал положительной разницы, используя эту настройку. По моему опыту, это привело к тому, что некоторые сценарии фактически выполнялись медленнее и имеют ужасную запись, иногда включающую выключение, пока скрипт все еще выполняется или даже в конце выполнения, пока веб-сервер все еще читает из буфера. Существует старый отчет об ошибке с 2013 года, нерешенный по состоянию на февраль 2017 года, который может быть связан: https://github.com/zendtech/ZendOptimizerPlus/issues/146
Я видел, что из-за этого ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR возникли следующие ошибки. Иногда регистрируются коррелятивные segfaults; иногда нет.
Если у вас есть один, проверьте ваш phpinfo и убедитесь, что opcache.fast_shutdown отключен.
Что ж. Недавно я тоже встретил этот вопрос. И, наконец, я получаю решения, которые действительно решают эту проблему.
Моей проблемой являются также страницы, которые не загружаются, и найти 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
Если есть какой-либо цикл или элемент, который не существует, вы сталкиваетесь с этой проблемой.
При запуске приложения в Chrome страница пуста и перестает отвечать на запросы.
Начало сценария:
Dev Environment: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,
в $ {myObj.getfName ()}
Окончание сценария:
Причина проблемы: функция getfName () не определена на myObj.
Надеюсь, это поможет вам.
я предполагаю, что сервер неправильно обрабатывает закодированное кодирование передачи. Для завершения работы с файлами с терминальными фрагментами необходимо передать терминальные фрагменты, чтобы указать, что весь файл был передан. Таким образом, может работать следующий код:
echo "\n"; flush(); ob_flush(); exit(0);
В моем случае было повреждено config для расширения mysqlnd_ms php на сервере. Забавно, что он работал нормально на запросах с небольшой продолжительностью. В журнале ошибок сервера было предупреждение, поэтому мы быстро его исправили.
Это похоже на общую проблему с несколькими причинами и решениями, поэтому я собираюсь ответить на этот вопрос всем, кто может это потребовать.
Я получал 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
brew uninstall php70-mongodb
и httpd -k restart
позже, и все было плавным.
В моем случае это была проблема с html. В ответ json возникла ошибка «\ n», вызвавшая проблему. Поэтому я удалил это.
Увлекательно видеть, как много разных причин для этой проблемы!
Многие говорят, что это проблема Chrome, поэтому я попробовал Safari и все еще имел проблемы. Затем попробовал все решения в этом потоке, в том числе отключить AVG Realtime Protection, не повезло.
Для меня проблема была в моем файле .htaccess
. Все это содержалось в FallbackResource index.php
, но когда я переименовал его в htaccess.txt
, моя проблема была решена.
Я получал net::ERR_INCOMPLETE_CHUNKED_ENCODING
, при ближайшем рассмотрении net::ERR_INCOMPLETE_CHUNKED_ENCODING
ошибок сервера я обнаружил, что это связано с тайм-аутом выполнения PHP-скрипта.
Добавление этой строки поверх скрипта PHP решило это для меня:
ini_set('max_execution_time', 300); //300 seconds = 5 minutes
Ссылка: Неустранимая ошибка: превышено максимальное время выполнения 30 секунд
В моем случае это происходило во время json-сериализации возвращаемой полезной нагрузки веб-api – у меня была «круговая» ссылка в моей модели Entity Framework, я возвращал простой граф объектов один-ко-многим, но у ребенка была ссылка на родитель, которому, по-видимому, сериализатор json не нравится. Удаление этого свойства у ребенка, которое ссылалось на родителя, сделало трюк.
Надеюсь, это поможет кому-то, у кого может быть подобная проблема.