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/isissue/detail?id=461213
• IIS & Chrome: не вдалося завантажити ресурс: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

ОНОВЛЕННЯ: Я зміг повторити цю помилку (нарешті), коли була скинута фатальна помилка, коли PHP (на тому ж localhost) був вихідним буферизацією . Я думаю, що результат був надто поганий, щоб бути корисним (заголовки, але вмісту мало або взагалі немає).

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

У мене було це питання. Простежив це, спробувавши більшість інших відповідей на це питання. Це було спричинено тим, що власник і дозволи, /var/lib/nginxа точніше, /var/lib/nginx/tmpкаталог невірні.

Каталог tmp використовується швидкими 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

OMG, я вирішив ту саму проблему 5 хвилин тому. Я витратив кілька годин на пошук рішення. На перший погляд відключення антивірусу вирішило проблему в Windows. Але тоді я помітив проблему на інших ПК з Linux без антивірусу. У журналах nginx немає помилок. Моя uwsgiпоказала щось про "Зламану трубу", але не на всі запити. Знаю, що? На пристрої не залишилося місця, яке я виявив, коли перезапустив сервер у журналі Database, і 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 (тобто багатобайтове).

Проблема виявилася в тому, як обчислювався заголовок довжини вмісту. Базовий вихідний сервер був обчисленням довжини символів, а не довжиною байтів. Вимкнення заголовків вмісту довжиною вирішило проблему тимчасово, поки я не змогла виправити систему зворотного шаблону.

Найпростіше рішення - збільшити proxy_read_timeout для встановленого місця проксі до більш високого значення (скажімо, 120s) у вашому 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 .

Наша платформа настрою раптом дуже повільно завантажувалася, на приладну панель завантажувалося приблизно 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/isissue/146

Я бачив, що такі помилки з'являються через цю ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Іноді в них записуються корелятивні сегментарні помилки; іноді ні.

Якщо у вас виникне будь-яке, перевірте свою phpinfo та переконайтесь, що opcache.fast_shutdown вимкнено.

Вибачте, сказати, я не маю для вас точної відповіді. Але я зіткнувся і з цією проблемою, і, принаймні, в моєму випадку, знайшов шлях. Тож, можливо, він запропонує підказки комусь іншому, хто знає більше про Php під кришкою.

Сценарій полягає в тому, що у мене масив переданий функції. Вміст цього масиву використовується для створення HTML-рядка, який слід відправити назад у браузер, розмістивши його всередині глобальної змінної, яка згодом надрукується. (Ця функція насправді нічого не повертає. Незнайко, я знаю, але це поруч із точкою.) Всередині цього масиву, серед іншого, є пара елементів, що містять, посиланням, вкладені асоціативні масиви, які були визначені поза цією функцією . Під час процесу усунення я виявив, що маніпулювання будь-яким елементом у цьому масиві в межах цієї функції, на яке посилається чи ні, включаючи спробу скидання цих посилаються елементів, призводить до того, що Chrome викидає чисту помилку :: 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();

?>

Сподіваюся, це допоможе комусь у майбутньому, і в моєму випадку це питання Касперського, але виправлення вище працює чудово :)

У моєму випадку це відбувалося під час серіалізації 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, коли я оглядаю сторінку та переходжу на вкладку ньюторк, я бачу, що сторінку 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/isissue/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 Realtime Protection, не пощастило.

Для мене проблемою був мій .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.