Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING error

Durante los últimos dos meses, he estado recibiendo el siguiente error en la consola de desarrollador de Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Síntomas

• Las páginas no se cargan.
• Archivos CSS y JS truncados.
• Páginas colgadas.

Entorno del servidor:

• Apache 2.2.22
• PHP
• Ubuntu

Esto me está sucediendo en nuestro servidor Apache interno. No le está sucediendo a nadie más, es decir, ninguno de nuestros usuarios está experimentando este problema, ni nadie más está en nuestro equipo de desarrollo.

Otras personas acceden exactamente al mismo servidor con la misma versión exacta de Chrome. También intenté deshabilitar todas las extensiones y navegar en modo incógnito, sin ningún efecto.

He usado Firefox y está ocurriendo exactamente lo mismo. Archivos truncados y demás. Lo único es que Firefox no genera ningún error de consola, por lo que debe inspeccionar la solicitud HTTP a través de Firebug para ver el problema.

Encabezados de respuesta de 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

Durante la prueba, pude solucionar el problema forzando HTTP 1.0 en mi archivo htaccess:

SetEnv downgrade-1.0

Esto elimina el problema. Sin embargo, forzar HTTP 1.0 sobre HTTP 1.1 no es una solución adecuada.

Actualización : como soy el único que experimenta este problema, pensé que necesitaba pasar más tiempo investigando si era o no un problema del lado del cliente. Si entro en la configuración de Chrome y uso la opción "Restaurar a los valores predeterminados", el problema desaparecerá durante unos 10-20 minutos. Entonces vuelve.

OKAY. Lo he probado tres veces y estoy 100% seguro de que está siendo causado por mi antivirus (ESET NOD32 ANTIVIRUS 5).

Cada vez que desactivo la protección en tiempo real, el problema desaparece. Hoy, dejé la protección en tiempo real desactivada durante 6-7 horas y el problema nunca ocurrió.

Hace unos momentos, lo volví a encender, solo para que el problema apareciera en un minuto.

En el transcurso de las últimas 24 horas, he activado y desactivado la protección en tiempo real, solo para asegurarme. Cada vez, el resultado ha sido el mismo.

Actualización: me encontré con otro desarrollador que tenía exactamente el mismo problema con la protección en tiempo real de su antivirus Kaspersky. Lo deshabilitó y el problema desapareció. es decir, este problema no parece estar limitado a ESET.

El error está tratando de decir que Chrome se cortó mientras se enviaba la página. Su problema es tratar de descubrir por qué.

Aparentemente, este podría ser un problema conocido que afecta a un par de versiones de Chrome. Por lo que puedo decir, es un problema de estas versiones que son masivamente sensibles a la longitud del contenido del fragmento que se envía y el tamaño expresado de ese fragmento (podría estar muy lejos de eso). En resumen, un problema de encabezados ligeramente imperfecto.

Por otro lado, podría ser que el servidor no envíe el fragmento de longitud 0 del terminal. Que podría ser reparable con ob_flush();. También es posible que Chrome (o conexión o algo) esté siendo lento. Entonces, cuando se cierra la conexión, la página aún no se ha cargado. No tengo idea de por qué esto podría suceder.

Aquí está la respuesta de los programadores paranoicos:

<?php
    // ... your code
    flush();
    ob_flush();
    sleep(2);
    exit(0);
?>

En su caso, podría ser un caso de tiempo de espera del script. No estoy realmente seguro de por qué debería afectar solo a usted, pero podría deberse a un montón de condiciones de carrera. Esa es una suposición absoluta. Debería poder probar esto extendiendo el tiempo de ejecución del script.

<?php
    // ... your while code
    set_time_limit(30);
    // ... more while code
?>

También puede ser tan simple como necesita actualizar su instalación de Chrome (ya que este problema es específico de Chrome).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS y Chrome: error al cargar el recurso: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

ACTUALIZACIÓN: pude replicar este error (por fin) cuando se produjo un error fatal mientras PHP (en el mismo localhost) emitía almacenamiento en búfer . Me imagino que la salida fue demasiado maltratada para ser de mucha utilidad (encabezados pero poco o ningún contenido).

Específicamente, accidentalmente tuve mi código recursivamente llamándose a sí mismo hasta que PHP, con razón, se rindió. Por lo tanto, el servidor no envió el fragmento de longitud 0 del terminal, que fue el problema que identifiqué anteriormente.

Tuve este problema Lo localizamos después de probar la mayoría de las otras respuestas a esta pregunta. Fue causado por el propietario y los permisos del directorio /var/lib/nginxy, más específicamente, el /var/lib/nginx/tmpdirectorio es incorrecto.

Fast-cgi utiliza el directorio tmp para almacenar en caché las respuestas a medida que se generan, pero solo si están por encima de cierto tamaño. Por lo tanto, el problema es intermitente y solo ocurre cuando la respuesta generada es grande.

Verifique nginx <host_name>.error_logsi tiene problemas con los permisos.

Para solucionarlo, asegúrese de que el propietario y el grupo de /var/lib/nginxtodos los subdirectorios sean nginx.

Lo siguiente debería solucionarlo para cada cliente.

//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));

Pero en mi caso, lo siguiente fue una mejor opción y también lo arreglé:

.htaccess:

php_value opcache.enable 0

Dios mío, resolví el mismo problema hace 5 minutos. Pasé varias horas para encontrar una solución. A primera vista, la desactivación del antivirus solucionó el problema en Windows. Pero luego noté un problema en otra PC de Linux sin antivirus. No hay errores en los registros nginx. Mi uwsgimostró algo sobre "tubería rota" pero no en todas las solicitudes. ¿Sabes que? No quedaba espacio en el dispositivo, lo cual encontré cuando reinicié el servidor en el registro de la base de datos, y lo dfaprobé. La única explicación acerca de por qué se resolvió el antivirus es que evita el almacenamiento en caché del navegador (debe verificar cada solicitud), pero el navegador con un comportamiento extraño puede simplemente ignorar la mala respuesta y mostrar las respuestas en caché.

En mi caso, tenía el /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)que probablemente resultaba del error Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

Tuve que eliminar /usr/local/var/run/nginx/y dejar que nginx lo creara nuevamente.

$ 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

Es conocido el problema de Chrome. Según los rastreadores de errores de Chrome y Chromium, no existe una solución universal para esto. Este problema no está relacionado con el tipo y la versión del servidor, está justo en Chrome.

Establecer Content-Encodingencabezado para identityresolver este problema para mí.

de developer.mozilla.org

identidad | Indica la función de identidad (es decir, sin compresión ni modificación).

Por lo tanto, puedo sugerir que, en algunos casos, Chrome no puede realizar la compresión gzip correctamente.

Acabo de ver que tenía un problema similar. Y noté que solo estaba sucediendo cuando la página contenía caracteres UTF-8 con un valor ordinal mayor que 255 (es decir, multibyte).

Lo que terminó siendo el problema fue cómo se calculaba el encabezado Content-Length. El backend subyacente fue calcular la longitud del carácter, en lugar de la longitud del byte. Desactivar los encabezados de longitud de contenido solucionó el problema temporalmente hasta que pude arreglar el sistema de plantillas de back-end.

La solución más fácil es aumentar el proxy_read_timeout para su ubicación de proxy establecida a un valor más alto (digamos 120s) en su nginx.conf.

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

Encontré esta solución aquí https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/

Cuando me enfrenté a este error (al hacer una llamada AJAX desde javascript); la razón fue que la respuesta del controlador fue errónea; estaba devolviendo un JSON que no tenía un formato válido.

Aquí el problema fue mi Avast AV. Tan pronto como lo desactivé, el problema desapareció.

Pero, realmente me gustaría entender la causa de este comportamiento.

Solo quería compartir mi experiencia con usted si alguien pudiera tener el mismo problema con MOODLE .

Nuestra plataforma Moodle fue repentinamente muy lenta, el tablero tardó aproximadamente 2-3 veces más en cargarse (hasta 6 segundos) de lo habitual y de vez en cuando algunas páginas no se cargaron (no un error 404 sino una página en blanco) ) En la Consola de herramientas para desarrolladores, estaba visible el siguiente error:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

Al buscar este error, parece que Chrome es el problema, pero tuvimos el problema con varios navegadores. Después de horas de investigación y comparación de las bases de datos de los días anteriores a que finalmente descubriera el problema, alguien activó el Monitoreo de eventos. Sin embargo, en el registro "Cambios de configuración", ¡este cambio no estaba visible! Desactivar la supervisión de eventos, finalmente resolvió el problema: no teníamos reglas definidas para la supervisión de eventos.

Estamos ejecutando Moodle 3.1.2+ con MariaDB y PHP 5.4.

Esto sucedía en dos servidores de clientes diferentes separados por varios años, utilizando el mismo código que se implementó en cientos de otros servidores durante ese tiempo sin problemas.

Para estos clientes, sucedió principalmente en scripts PHP que tenían HTML en streaming, es decir, "Conexión: cerrar" páginas donde la salida se enviaba al navegador a medida que la salida estaba disponible.

Resultó que la conexión entre el proceso PHP y el servidor web se estaba cayendo prematuramente, antes de que se completara el script y mucho antes de que se agotara el tiempo de espera.

El problema era opcache.fast_shutdown = 1 en el archivo php.ini principal. Esta directiva está deshabilitada de manera predeterminada, pero parece que algunos administradores de servidores creen que hay un aumento de rendimiento aquí. En todas mis pruebas, nunca noté una diferencia positiva al usar esta configuración. En mi experiencia, ha provocado que algunos scripts se ejecuten realmente más lentamente, y tiene un historial terrible de que a veces ingrese al apagado mientras el script aún se está ejecutando, o incluso al final de la ejecución mientras el servidor web todavía está leyendo desde el búfer. Hay un informe de error antiguo de 2013, no resuelto hasta febrero de 2017, que puede estar relacionado: https://github.com/zendtech/ZendOptimizerPlus/issues/146

He visto aparecer los siguientes errores debido a este ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR A veces hay segfaults correlativos registrados; a veces no.

Si experimenta cualquiera de los dos, verifique su phpinfo y asegúrese de que opcache.fast_shutdown esté deshabilitado.

Lamento decir que no tengo una respuesta precisa para ti. Pero también encontré este problema y, al menos en mi caso, encontré una solución. Entonces, tal vez ofrecerá algunas pistas a alguien más que sepa más sobre Php bajo el capó.

El escenario es que tengo una matriz pasada a una función. El contenido de esta matriz se está utilizando para producir una cadena HTML que se enviará de vuelta al navegador, colocándolo todo dentro de una variable global que luego se imprimirá. (Esta función en realidad no devuelve nada. Descuidado, lo sé, pero eso no viene al caso.) Dentro de esta matriz, entre otras cosas, hay un par de elementos que llevan, por referencia, matrices asociativas anidadas que se definieron fuera de esta función. . Mediante el proceso de eliminación, descubrí que la manipulación de cualquier elemento dentro de esta matriz dentro de esta función, referenciada o no, incluido un intento de desarmar esos elementos referenciados, hace que Chrome arroje un error net :: ERR_INCOMPLETE_CHUNKED_ENCODING y no muestre contenido.

Solo al volver a utilizar el script para que no aplique referencias a los elementos de la matriz en primer lugar, las cosas comenzaron a funcionar normalmente nuevamente. Sospecho que esto es realmente un error de Php que tiene algo que ver con la presencia de los elementos referenciados que arrojan los encabezados de longitud de contenido, pero realmente no sé lo suficiente para decirlo con certeza.

Tuve este problema con un sitio en Chrome y Firefox. Si apagué el Avast Web Shield, desapareció. Parece que he logrado que funcione con Web Shield ejecutándose agregando algunos de los htaccess html5 boilerplate a mi archivo 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>

Mi solución es:

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

ob_flush();

?>

Espero que esto ayude a alguien en el futuro, y en mi caso es un problema de Kaspersky, pero la solución anterior funciona muy bien :)

En mi caso, estaba sucediendo durante la serialización json de una carga útil de retorno de API web: tenía una referencia 'circular' en mi modelo de Entity Framework, estaba devolviendo un simple gráfico de objeto uno a muchos, pero el niño tenía una referencia de nuevo a el padre, que aparentemente no le gusta al serializador json. Quitar la propiedad del niño que hacía referencia al padre hizo el truco.

Espero que esto ayude a alguien que pueda tener un problema similar.

Verifique el permiso de la carpeta nginx y configure el permiso de apariencia para eso:

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

Estaba obteniendo net::ERR_INCOMPLETE_CHUNKED_ENCODING, tras una inspección más cercana de los registros de errores del servidor, descubrí que se debía al tiempo de espera de ejecución del script PHP.

Agregar esta línea encima del script PHP lo resolvió para mí:

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

Ref: error grave: tiempo de ejecución máximo de 30 segundos excedido

Para mí fue causado por el espacio libre insuficiente en el disco duro.

esto me estaba sucediendo por una razón completamente diferente. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 cuando inspecciono la página y voy a la pestaña newtork, veo que la página vendor.js no se pudo cargar. Al verificar, parece que el tamaño del archivo js es grande ~ 6.5 mb. Eso es cuando me di cuenta de que necesitaba comprimir el js. Verifiqué que estaba usando el ng buildcomando para construir. En cambio, cuando lo usé ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizerfuncionó para mí. Ver https://github.com/angular/angular-cli/issues/9016

Bien. No hace mucho, también me encontré con esta pregunta. Y finalmente obtengo las soluciones que realmente abordan este problema.

Los síntomas de mi problema también son que las páginas no se cargan y encuentran que los datos json se truncaron al azar.

Aquí están las soluciones que resumo podrían ayudar a resolver este problema.

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

Si hay algún bucle o elemento que no existe, entonces se enfrenta a este problema.

Al ejecutar la aplicación en Chrome, la página está en blanco y deja de responder.

Inicio de escenario:

Entorno de desarrollo: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

en $ {myObj.getfName ()}

Fin del escenario:

Razón del problema: la función getfName () no está definida en myObj.

Espero que te ayude.

Supongo que el servidor no está manejando correctamente la codificación de transferencia fragmentada. Tiene que poner un terminal en un archivo fragmentado con un fragmento terminal para indicar que se ha transferido todo el archivo, por lo que el siguiente código puede funcionar:

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

En mi caso, se rompió la configuración de la extensión mysqlnd_ms php en el servidor. Lo curioso es que funcionaba bien en solicitudes de corta duración. Hubo una advertencia en el registro de errores del servidor, por lo que lo hemos solucionado rápidamente.

Esto parece un problema común con múltiples causas y soluciones, por lo que voy a poner mi respuesta aquí para cualquiera que lo requiera.

Estuve obteniendo net::ERR_INCOMPLETE_CHUNKED_ENCODING usando Chrome, osx, php70, combinación httpd24, pero el mismo código funcionó bien en el servidor de producción.

Inicialmente seguí los registros regulares, pero nada apareció realmente. Una ls -latermuestra rápida system.logfue el último archivo tocado /var/log, y las colas que me dieron

Saved crash report for httpd[99969] version 2.4.16 (805) 
to /Library/Logs/DiagnosticReports/httpd.crash

Contenido dentro de:

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-mongodby httpd -k restartdespués y todo fue fácil.

En mi caso fue cuestión de html. Hubo '\ n' en la respuesta de json causando el problema. Entonces quité eso.

¡Fascinante ver cuántas causas diferentes hay para este problema!

Muchos dicen que es un problema de Chrome, así que probé Safari y aún tuve problemas. Luego probé todas las soluciones en este hilo, incluida la desactivación de mi AVG Realtime Protection, sin suerte.

Para mí, el problema era mi .htaccessarchivo. Todo lo que contenía era FallbackResource index.php, pero cuando le cambié el nombre htaccess.txt, mi problema se resolvió.

Hmmm, me topé con un problema similar pero con diferentes razones detrás ...

Estoy usando Laravel Valet en un proyecto PHP vainilla con Laravel Mix . Cuando abrí el sitio en Chrome, arrojaba net::ERR_INCOMPLETE_CHUNKED_ENCODINGerrores. (Si tenía el sitio cargado en el protocolo HTTPS, el error cambió a net::ERR_SPDY_PROTOCOL_ERROR).

Lo comprobé php.iniy opcacheno estaba habilitado. Descubrí que en mi caso el problema estaba relacionado con el control de versiones de los archivos de activos; por alguna razón, no parecía gustarle una cadena de consulta en la URL de los activos (bueno, curiosamente, ¿solo uno en particular?).

He eliminado mix.version()para el entorno local, y el sitio se carga muy bien en mi Chrome en los protocolos HTTP y HTTPS.

En el contexto de un controlador en Drupal 8 (Symfony Framework), esta solución funcionó para mí:

$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;

De lo contrario, el encabezado de respuesta 'Transfer-Encoding' obtuvo un valor 'fragmentado'. Esto puede ser un problema para el navegador Chrome.