resource net err_incomplete_chunked_encoding php apache google-chrome chunked-encoding chunked

php - net - err_incomplete_chunked_encoding webpack



Chrome net:: ERR_INCOMPLETE_CHUNKED_ENCODING error (30)

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 en nuestro equipo de desarrollo.

Otras personas acceden exactamente al mismo servidor con la misma versión exacta de Chrome. También he intentado 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.

¡Es 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 archivo .htaccess . Todo lo que contenía era FallbackResource index.php , pero cuando le htaccess.txt nombre a htaccess.txt , mi problema se resolvió.

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.

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.

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

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.

Dios mío, tuve 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 Linux sin antivirus. No hay errores en los registros nginx. Mi uwsgi mostró algo sobre "tubería rota" pero no en todas las solicitudes. ¿Sabes que? No quedaba espacio en el dispositivo, lo que encontré cuando reinicié el servidor en el registro de la base de datos, y df aprobó. 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 simplemente puede ignorar la mala respuesta y mostrar las respuestas en caché.

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. Lo que podría ser ob_flush(); 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 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).

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 el resultado fue demasiado maltratado 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 de la terminal, que fue el problema que identifiqué anteriormente.

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.

En mi caso estaba teniendo /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied) que probablemente resultó en el error Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

Tuve que eliminar /usr/local/var/run/nginx/ y dejar que nginx lo vuelva a crear.

$ 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

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

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.

En mi caso, sucedía durante la serialización json de una carga útil de retorno de la API web: tenía una referencia ''circular'' en mi modelo de Entity Framework, estaba devolviendo un simple gráfico de objetos 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.

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 el encabezado de Content-Encoding en identity resolvió este problema.

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.

Estaba obteniendo net::ERR_INCOMPLETE_CHUNKED_ENCODING , después de 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

Esto generalmente aumenta cuando el cliente envía una ráfaga de solicitudes al servidor, junto a un evento del lado del cliente.

Esto generalmente es un signo de programación "mala" en el lado del cliente.

Imagina que estoy actualizando todas las líneas de una tabla.

La mala manera es enviar una solicitud para actualizar cada fila (muchas solicitudes en rafale sin esperar a que se complete la solicitud). Para corregirlo, asegúrese de que la solicitud esté completa antes de enviar otra.

La buena manera sería enviar una solicitud con todas las filas actualizadas. (Una solicitud)

Entonces, al principio, mire lo que está sucediendo en el lado del cliente y refactorice el código si es necesario.

Use wireshark para identificar qué sale mal en las solicitudes.

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.

Estaba obteniendo net::ERR_INCOMPLETE_CHUNKED_ENCODING en 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. Un rápido ls -later system.log mostró que system.log fue el último archivo tocado en /var/log , y el seguimiento me dio

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

Contenida 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

Una brew uninstall php70-mongodb y un httpd -k restart más tarde y todo fue brew uninstall php70-mongodb .

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 tiempo real, es decir, "Conexión: cerrar" páginas donde la salida se enviaba al navegador cuando 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 forma predeterminada, pero parece que algunos administradores de servidores creen que hay un aumento de rendimiento aquí. En todas mis pruebas, nunca he notado 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.

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 errores net::ERR_INCOMPLETE_CHUNKED_ENCODING . (Si tenía el sitio cargado en el protocolo HTTPS, el error cambió a net::ERR_SPDY_PROTOCOL_ERROR ).

opcache el php.ini y opcache no estaba habilitado. Descubrí que en mi caso el problema estaba relacionado con la versión 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.

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.

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

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

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ándola 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. Esto a pesar del hecho de que la cadena HTML en la variable global es exactamente lo que debería ser.

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.

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, la siguiente fue una mejor opción y también lo arregló:

.htaccess:

php_value opcache.enable 0

Mi solución es:

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

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 :)

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 saliera a la superficie 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.

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.

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 en absoluto (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.

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

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/nginx y, más específicamente, el directorio /var/lib/nginx/tmp 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.

Compruebe el nginx <host_name>.error_log para ver si tiene problemas con los permisos.

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

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:

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

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

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