Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING ошибка

В течение последних двух месяцев я получал следующую ошибку на консоли разработчика Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Симптомы:

• Страницы не загружаются.
• Усеченные файлы CSS и JS.
• Страницы висят.

Серверная среда:

• Apache 2.2.22
• PHP
• Ubuntu

Это происходит со мной на нашем собственном сервере 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();. Также возможно, что 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

ОБНОВИТЬ: я смог воспроизвести эту ошибку (наконец), когда возникла фатальная ошибка, когда 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

О боже, я решил ту же проблему 5 минут назад. Я потратил несколько часов, чтобы найти решение. На первый взгляд отключение антивируса решило проблему на Windows. Но затем я заметил проблему на другом компьютере с Linux без антивируса. Нет ошибок в логах nginx. Мой uwsgiпоказал что-то про "Разбитую трубу", но не по всем запросам. Знаешь что? На устройстве не осталось места, которое я обнаружил при перезапуске сервера в журнале базы данных и dfподтвердил это. Единственное объяснение того, почему антивирус был решен, заключается в том, что он предотвращает кэширование браузера (он должен проверять каждый запрос), но браузер с некоторым странным поведением может просто игнорировать неверный ответ и отображать кэшированные ответы.

В моем случае я имел, /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

Это известная проблема Chrome. По мнению Chrome и Chromium, для этого нет универсального решения. Эта проблема не связана с типом и версией сервера, она прямо в Chrome.

Установка Content-Encodingзаголовка для identityрешения этой проблемы для меня.

с сайта developer.mozilla.org

личность | Указывает на тождественную функцию (т.е. без сжатия или модификации).

Итак, я могу предположить, что в некоторых случаях Chrome не может правильно выполнить сжатие gzip.

Я просто столкнулся с похожей проблемой. И заметил, что это происходило только тогда, когда страница содержала символы UTF-8 с порядковым номером больше 255 (т.е. многобайтовые).

В конечном итоге проблема заключалась в том, как вычислялся заголовок Content-Length. Базовый бэкэнд вычислял длину символа, а не байта. Отключение заголовков длины содержимого временно устранило проблему, пока я не исправил систему шаблонов серверной части.

Самое простое решение - увеличить 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/

Когда я столкнулся с этой ошибкой (при вызове AJAX из javascript); причина в том, что ответ от контроллера был ошибочным; он возвращал JSON недопустимого формата.

Здесь проблема была в моем Avast AV. Как только я отключил его, проблема исчезла.

Но мне очень хотелось бы понять причину такого поведения.

Я просто хотел поделиться с вами своим опытом, если у кого-то может быть такая же проблема с MOODLE .

Наша платформа Moodle внезапно стала очень медленной, панель инструментов загружалась примерно в 2-3 раза дольше (до 6 секунд), чем обычно, и время от времени некоторые страницы вообще не загружались (не ошибка 404, а пустая страница ). В консоли инструментов разработчика была видна следующая ошибка:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

При поиске этой ошибки выясняется, что проблема связана с Chrome, но у нас были проблемы с различными браузерами. После нескольких часов исследований и сравнения баз данных за несколько дней до того, как я наконец обнаружил проблему, кто-то включил мониторинг событий. Однако в журнале «Изменения конфигурации» это изменение не было видно! Отключение мониторинга событий окончательно решило проблему - у нас не было определенных правил для мониторинга событий.

Мы используем Moodle 3.1.2+ с MariaDB и PHP 5.4.

Это происходило на двух разных клиентских серверах, разделенных несколькими годами, с использованием того же кода, который в то время без проблем был развернут на сотнях других серверов.

Для этих клиентов это происходило в основном с 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 Иногда регистрируются соответствующие ошибки сегментации; иногда нет.

Если вы столкнулись с одним из них, проверьте свой phpinfo и убедитесь, что opcache.fast_shutdown отключен.

Сожалею, но у меня нет для вас точного ответа. Но я тоже столкнулся с этой проблемой и, по крайней мере, в моем случае, нашел способ ее обойти. Так что, возможно, он подскажет кому-то еще, кто знает больше о Php под капотом.

Сценарий такой: у меня есть массив, переданный функции. Содержимое этого массива используется для создания HTML-строки, которая будет отправлена ​​обратно в браузер, путем помещения ее в глобальную переменную, которая позже будет напечатана. (Эта функция на самом деле ничего не возвращает. Небрежно, я знаю, но это не относится к делу.) Внутри этого массива, помимо прочего, находится пара элементов, несущих по ссылке вложенные ассоциативные массивы, которые были определены вне этой функции. , Путем исключения я обнаружил, что манипуляции с любым элементом внутри этого массива внутри этой функции, на которые есть ссылка или нет, включая попытку отключить эти элементы, приводят к тому, что Chrome выдает ошибку net :: ERR_INCOMPLETE_CHUNKED_ENCODING и не отображает никакого содержимого.

Только переоборудовав скрипт, чтобы в первую очередь не применять ссылки к элементам массива, все снова стало нормально работать. Я подозреваю, что на самом деле это ошибка Php, имеющая какое-то отношение к присутствию элементов, на которые есть ссылки, которые отбрасывают заголовки длины содержимого, но я действительно не знаю об этом достаточно, чтобы сказать наверняка.

У меня была эта проблема с сайтом в Chrome и Firefox. Если я отключил Avast Web Shield, он исчезнет. Кажется, мне удалось заставить его работать с запущенным Web Shield, добавив некоторые из шаблонных htaccess html5 в мой файл 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>

Мое исправление:

<?php  ob_start(); ?>
<!DOCTYPE html>
<html lang="de">
.....
....//your whole code
....
</html>
<?php
        ob_clean();
ob_end_flush();

ob_flush();

?>

Надеюсь, это поможет кому-то в будущем, и в моем случае это проблема с Kaspersky, но исправление выше отлично работает :)

В моем случае это происходило во время json-сериализации полезной нагрузки, возвращаемой веб-API - у меня была `` круговая '' ссылка в моей модели Entity Framework, я возвращал простой граф объектов один-ко-многим обратно, но у ребенка была ссылка на родительский элемент, который явно не нравится сериализатору json. Удаление свойства дочернего элемента, ссылающегося на родителя, помогло.

Надеюсь, это поможет кому-то, у кого может быть аналогичная проблема.

Проверьте разрешение папки nginx и установите для этого разрешение appache:

chown -R www-data:www-data /var/lib/nginx

Я получал net::ERR_INCOMPLETE_CHUNKED_ENCODING, при более внимательном рассмотрении журналов ошибок сервера я обнаружил, что это произошло из-за тайм-аута выполнения скрипта PHP.

Добавление этой строки поверх PHP-скрипта решило эту проблему для меня:

ini_set('max_execution_time', 300); //300 seconds = 5 minutes

Ссылка: Неустранимая ошибка: превышено максимальное время выполнения 30 секунд

Для меня это было вызвано нехваткой свободного места на жестком диске.

это происходило для меня совсем по другой причине. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200, когда я проверяю страницу и перехожу на вкладку newtork, я вижу, что страница vendor.js не загрузилась. После проверки кажется, что размер js-файла большой ~ 6.5 Мб. Тогда я понял, что мне нужно сжать js. Я проверил, что использую ng buildкоманду для сборки. Вместо этого, когда я использовал, ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizerэто сработало для меня. См. Https://github.com/angular/angular-cli/issues/9016

Хорошо. Не так давно я тоже встретил этот вопрос. И, наконец, я получаю решения, которые действительно решают эту проблему.

Мои симптомы проблемы также заключаются в том, что страницы не загружаются и обнаруживают, что данные 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 страница становится пустой и не отвечает.

Начало сценария:

Среда разработки: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

в $ {myObj.getfName ()}

Конец сценария:

Причина проблемы: функция getfName () не определена в myObj.

Надеюсь, это поможет вам.

Я предполагаю, что сервер неправильно обрабатывает фрагментированное кодирование передачи. Чтобы указать, что весь файл был передан, необходимо завершить фрагменты файлов с помощью фрагмента терминала, поэтому приведенный ниже код может работать:

echo "\n";
flush();
ob_flush();
exit(0);

В моем случае это была сломанная конфигурация для расширения 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, не повезло.

Для меня проблема заключалась в моем .htaccessфайле. Все, что он содержал, было FallbackResource index.php, но когда я переименовал его в htaccess.txt, моя проблема была решена.

Хммм, я только что наткнулся на похожую проблему, но по другим причинам ...

Я использую Laravel Valet в ванильном PHP-проекте с Laravel Mix . Когда я открывал сайт в Chrome, он выдавал net::ERR_INCOMPLETE_CHUNKED_ENCODINGошибки. (Если бы у меня был сайт, загруженный по протоколу HTTPS, ошибка изменилась бы на net::ERR_SPDY_PROTOCOL_ERROR.)

Я проверил php.iniи opcacheне был включен. Я обнаружил, что в моем случае проблема была связана с версией файлов ресурсов - по какой-то причине ей не нравилась строка запроса в URL-адресе ресурсов (ну, как ни странно, только одна в частности?).

Я удалил его mix.version()для локальной среды, и сайт отлично загружается в моем Chrome по протоколам HTTP и HTTPS.

В контексте контроллера в 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.