Ошибка Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODING

OK. Я трижды проверил это и уверен на 100%, что это вызвано моим антивирусом (ESET NOD32 ANTIVIRUS 5).

Всякий раз, когда я отключаю защиту в реальном времени, проблема исчезает. Сегодня я оставил защиту реального времени отключенной на 6-7 часов, и проблема так и не возникла.

Несколько минут назад я снова включил ее, но проблема возникла через минуту.

В течение последних 24 часов я снова включал и выключал защиту реального времени, просто чтобы убедиться в этом. Каждый раз результат был один и тот же.

Обновление: Я обнаружил другого разработчика, у которого была точно такая же проблема с защитой Real-Time на его антивирусе Касперского. Он отключил ее, и проблема исчезла. Т.е. эта проблема, похоже, не ограничивается 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
• https://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-resource-neterr-incomplete-chunked-encoding
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

UPDATE: Я смог воспроизвести эту ошибку (наконец-то), когда фатальная ошибка возникала, когда PHP (на том же localhost) выполнял буферизацию вывода. Я полагаю, что вывод был слишком сильно искажен, чтобы быть полезным (заголовки, но мало или совсем нет содержимого).

В частности, я случайно заставил свой код рекурсивно вызывать самого себя, пока PHP, что вполне справедливо, не сдался. Таким образом, сервер не отправил терминальный кусок длиной 0 - это и была проблема, которую я определил ранее.

У меня была эта проблема. Отследила его после попытки большинство других ответов на этот вопрос. Это было вызвано владельца и прав доступа на каталог/var/lib в/с nginxа точнее/ВАР/Либ/nginx в/tmp, в каталог неверна.

Каталог tmp используется фаст-цги для кэширования ответов, как они генерируются, только если они превышают определенный размер. Итак, проблема возникает периодически и возникает только тогда, когда производимая ответ большой.

Проверьте, что nginx <хост>.функцию error_log`, чтобы увидеть, если у вас возникли проблемы с разрешениями.

Чтобы исправить, того, чтобы владелец и группа `/ВАР/Либ/с nginx и всех подкаталогах руках.

Следующее должно исправить это для каждого клиента.

<?php

//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'а. Мой сервером показали что-то о том, что "Труба", но не на все запросы. Знаете, что? Он был нет места на диске, который я нашел после перезагрузки сервера в журнале базы данных, и ДФ утвердил это. Единственное объяснение о том, почему антивирус был решить это, что он предотвращает кэширование в браузере (он должен проверить каждый запрос), но браузер с некоторыми странное поведение может просто игнорировать неправильный ответ и показать кэшированные ответы.

Это известная проблема хрома. По данным хрома и хрома баг-трекеров не существует универсального решения для этого. Эта проблема не связана с типом сервера и версии, это правильно в Chrome.

Установка контент-кодированиязаголовокЛичность` решил эту проблему для меня.

от developer.mozilla.org

удостоверение | указывает на функцию идентификации (т. е. без сжатия, ни В модификации).

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

В моем случае у меня был /usr/местные/ВАР/работа/nginx в/fastcgi_temp/3/07/0000000073" и не удалось (13: отказано в доступе), который был, вероятно, в результате чего хром объем::ошибка ERR_INCOMPLETE_CHUNKED_ENCODING.

Мне пришлось удалить /usr/местные/ВАР/работа/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

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

Самое простое решение-увеличить когда за задать местоположение прокси-сервера на более высокое значение (скажем 120С) в файле nginx.конф.

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

Я нашел это решение здесь https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

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

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

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

Для этих клиентов, это произошло в основном на PHP-скрипты, которые потокового HTML - то есть, то "соединение: рядом с" страницы, на которых выход был отправлен в браузер в качестве вывода стала доступной.

Оказалось, что связь между процессом PHP и веб-сервер падал преждевременно, до завершения скрипта и до таймаута.

Проблема была опдачи.fast_shutdown = 1 в основном на PHP.ini-файл. Эта директива отключена по умолчанию, но, похоже, некоторые администраторы серверов считаем, что повышение производительности было здесь. Во всех моих тестах я не заметил положительную разницу, используя этот параметр. По моему опыту, это вызвало некоторые скрипты, чтобы фактически выполнить более медленно, и есть ужасный послужной список иногда заходят выключения пока скрипт все еще выполняется, или даже в конце выполнения веб сервер читает из буфера. Есть старый баг-репорт с 2013 года, нерешенных состоянию на 2017 февраля, что может быть связано: https://github.com/zendtech/ZendOptimizerPlus/issues/146

Я видел следующие ошибки появляются из-за этого ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Иногда есть соотносительное вылеты вход; иногда нет.

Если вы испытываете один, проверить функцию phpinfo, и убедитесь, что опдачи.fast_shutdown отключена.

Вот проблема была у меня Аваст АВ. Как только я отключил его, проблема исчезла.

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

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

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

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

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

Я имел эту проблему с сайтом в браузере Chrome и Firefox. Если я отключил Аваст и веб-щит он ушел. Я, кажется, не удалось заставить его работать с веб-щит, добавив некоторые HTML5 шаблонный 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.



    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"



# ------------------------------------------------------------------------------
# | Compression                                                                |
# ------------------------------------------------------------------------------



    # Force compression for mangled headers.
    # http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping


            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



    # 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 `` and `` lines
    #  as `AddOutputFilterByType` is still in the core directives).

        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




# ------------------------------------------------------------------------------
# | 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!


    Header set Connection Keep-Alive

Я просто хотела поделиться с вами своим опытом, если кто-то может есть такая же проблема с МУДЛ.

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

Поиск этой ошибки, похоже, что Хром-это проблема, но у нас были проблемы с различными браузерами. После нескольких часов исследований и сравнения баз данных от дней, прежде чем я, наконец, нашел проблему, кто-то включил мониторинг событий на. Однако, в "Настройки" и журнал, это изменение было'т видна! Поворотным событием мониторинга выключен, наконец-то решена проблема - у нас нет правил, определенных для мониторинга событий.

Мы'вновь работает Мудл 3.1.2+ с MariaDB и на PHP 5.4.

Мое решение такое:

<?php  ob_start(); ?>


.....
....//your whole code
....

<?php
        ob_clean();
ob_end_flush();

ob_flush();

?>

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

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

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

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

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

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

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

Интересно посмотреть, как много разных причин есть по этому вопросу!

Многие говорят, что это'ов проблемы с Chrome, так что я попробовал сафари и еще были проблемы. Потом перепробовали все решения в этой теме, включая и выключая мой AVG защита в реальном времени, не повезло.

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