Erreur Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING

Au cours des deux derniers mois, j’ai reçu l’erreur suivante sur la console de développement de Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING 

Symptômes:

  • Pages non chargées.
  • Fichiers CSS et JS tronqués.
  • Pages suspendues

Environnement serveur:

  • Apache 2.2.22
  • PHP
  • Ubuntu

Cela m’arrive sur notre serveur Apache interne. Cela n’arrive à personne d’autre – c’est-à-dire qu’aucun de nos utilisateurs ne rencontre ce problème – et que personne d’autre ne fait partie de notre équipe de développement.

D’autres personnes accèdent au même serveur avec la même version de Chrome. J’ai également essayé de désactiver toutes les extensions et de naviguer en mode Incognito – sans effet.

J’ai utilisé Firefox et la même chose se produit. Fichiers tronqués et autres joyeusetés. La seule chose est que Firefox ne génère aucune erreur de console. Vous devez donc inspecter la requête HTTP via Firebug pour voir le problème.

En-têtes de réponse d’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 

En testant, j’ai pu résoudre le problème en forçant HTTP 1.0 dans mon fichier htaccess:

 SetEnv downgrade-1.0 

Cela élimine le problème. Cependant, forcer HTTP 1.0 via HTTP 1.1 n’est pas une solution appropriée.

Mise à jour : Étant donné que je suis le seul à être confronté à ce problème, j’ai pensé que je devais passer plus de temps à rechercher s’il s’agissait ou non d’un problème côté client. Si je vais dans les parameters de Chrome et que j’utilise l’option “Restaurer les valeurs par défaut”, le problème disparaîtra pendant environ 10 à 20 minutes. Ensuite, il revient.

D’ACCORD. Je l’ai testé trois fois et je suis sûr à 100% qu’il est causé par mon anti-virus (ESET NOD32 ANTIVIRUS 5).

Chaque fois que je désactive la protection en temps réel, le problème disparaît. Aujourd’hui, j’ai quitté la protection en temps réel pendant 6 à 7 heures et le problème ne s’est jamais produit.

Il y a quelques instants, je l’ai réactivé, uniquement pour que le problème apparaisse dans une minute.

Au cours des dernières 24 heures, j’ai activé et désactivé la protection en temps réel, juste pour être sûr. Chaque fois – le résultat a été le même.

Mise à jour: J’ai rencontré un autre développeur qui avait exactement le même problème avec la protection en temps réel sur son anti-virus Kaspersky. Il l’a désactivé et le problème a disparu. Ce problème ne semble pas se limiter à ESET.

L’erreur tente de dire que Chrome a été coupé pendant l’envoi de la page. Votre problème est d’essayer de comprendre pourquoi.

Apparemment, cela pourrait être un problème connu affectant quelques versions de Chrome. Autant que je sache, il s’agit d’un problème de sensibilité de ces versions à la longueur du contenu envoyé et à la taille exprimée de ce morceau (je pourrais être très loin sur ce point). En bref, un problème d’en-tête légèrement imparfait.

D’autre part, il se peut que le serveur n’envoie pas le bloc de longueur 0 du terminal. Qui pourrait être ob_flush(); avec ob_flush(); . Il est également possible que Chrome (ou la connexion ou quelque chose) soit lent, donc lorsque la connexion est fermée, la page n’est pas encore chargée. Je ne sais pas pourquoi cela pourrait arriver.

Voici la réponse des programmeurs paranoïaques:

  

Dans votre cas, il pourrait s’agir d’un script expirant. Je ne suis pas vraiment sûr de savoir pourquoi cela ne devrait affecter que vous, mais cela pourrait être fait dans un tas de conditions de course? C’est une supposition absolue. Vous devriez pouvoir le tester en prolongeant le temps d’exécution du script.

  

Il peut également être aussi simple que nécessaire pour mettre à jour votre installation Chrome (comme ce problème est spécifique à Chrome).

MISE À JOUR: J’ai pu répliquer cette erreur (enfin) lorsqu’une erreur fatale a été générée alors que PHP (sur le même hôte local) était en sortie de mémoire tampon . J’imagine que la sortie était trop mal faite pour être très utile (en-têtes mais peu ou pas de contenu).

Plus précisément, mon code s’est accidentellement appelé jusqu’à ce que PHP, à juste titre, abandonne. Ainsi, le serveur n’a pas envoyé le bloc de longueur 0 du terminal – ce qui était le problème que j’ai identifié précédemment.

J’ai eu ce problème. Suivi après avoir essayé la plupart des autres réponses sur cette question. Cela était dû au propriétaire et aux permissions du répertoire /var/lib/nginx et plus précisément au /var/lib/nginx/tmp étant incorrect.

Le répertoire tmp est utilisé par fast-cgi pour mettre en cache les réponses au fur et à mesure de leur génération, mais uniquement si elles dépassent une certaine taille. Le problème est donc intermittent et ne se produit que lorsque la réponse générée est importante.

Vérifiez le nginx .error_log pour voir si vous rencontrez des problèmes d’autorisation.

Pour corriger, assurez-vous que le propriétaire et le groupe de /var/lib/nginx et tous les sous-répertoires sont nginx.

Ce qui suit devrait résoudre ce problème pour chaque client.

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

Mais dans mon cas, ce qui suit était une meilleure option et l’a également corrigé:

.htaccess:

 php_value opcache.enable 0 

OMG, j’ai eu le même problème il y a 5 minutes. J’ai passé plusieurs heures à trouver une solution. A première vue, la désactivation de l’antivirus a résolu le problème sous Windows. Mais alors j’ai remarqué un problème sur les autres PC Linux sans antivirus. Aucune erreur dans les journaux nginx. Mon uwsgi montré quelque chose sur “pipe cassée” mais pas sur toutes les demandes. Savoir quoi? Il n’y avait plus d’espace sur le périphérique, que j’ai trouvé lors du redémarrage du serveur dans le journal de la firebase database, et que df approuvé. La seule explication de la raison pour laquelle l’antivirus a été résolu est qu’il empêche la mise en cache du navigateur (il doit vérifier chaque requête), mais le navigateur avec un comportement étrange peut simplement ignorer la mauvaise réponse et afficher les réponses mises en cache.

Il est connu problème Chrome. Selon les trackers de bogues Chrome et Chromium, il n’y a pas de solution universelle pour cela. Ce problème n’est pas lié au type et à la version du serveur, il est correct dans Chrome.

La définition de l’en Content-Encoding tête Content-Encoding sur l’ identity résolu ce problème.

de developer.mozilla.org

identité | Indique la fonction d’identité (c’est-à-dire sans compression, ni modification).

Donc, je peux suggérer que, dans certains cas, Chrome ne peut pas effectuer correctement la compression gzip.

Ici, le problème était mon AV Avast. Dès que je l’ai désactivé, le problème a disparu.

Mais je voudrais vraiment comprendre la cause de ce comportement.

Cela se passait sur des serveurs de deux clients différents, séparés de plusieurs années, en utilisant le même code qui était déployé sur des centaines d’autres serveurs pour cette période sans problème.

Pour ces clients, la plupart des scripts PHP contenaient du HTML en continu, c’est-à-dire des pages “Connexion: fermer” où la sortie était envoyée au navigateur dès que la sortie était disponible.

Il s’est avéré que la connexion entre le processus PHP et le serveur Web était prématurée, avant la fin du script et avant le délai d’attente.

Le problème était opcache.fast_shutdown = 1 dans le fichier php.ini principal. Cette directive est désactivée par défaut, mais il semble que certains administrateurs de serveur estiment qu’il ya une amélioration des performances à obtenir ici. Dans tous mes tests, je n’ai jamais noté de différence positive en utilisant ce paramètre. D’après mon expérience, certains scripts ont été exécutés plus lentement, et leur historique de mise hors tension pendant l’exécution du script, ou même à la fin de l’exécution alors que le serveur Web est toujours en train de lire, est terrible. Il y a un vieux rapport de bogue de 2013, non résolu en février 2017, qui peut être lié: https://github.com/zendtech/ZendOptimizerPlus/issues/146

J’ai vu les erreurs suivantes apparaître à cause de cela ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Parfois, des erreurs de segmentation corrélatives sont enregistrées; parfois pas.

Si vous rencontrez l’un ou l’autre, vérifiez votre phpinfo et assurez-vous que opcache.fast_shutdown est désactivé.

Je viens de regarder un problème similaire. Et remarqué que cela ne se produisait que lorsque la page contenait des caractères UTF-8 avec une valeur ordinale supérieure à 255 (c’est-à-dire multi-octets).

Ce qui a fini par être le problème était la façon dont l’en-tête Content-Length était calculé. Le backend sous-jacent calculait la longueur des caractères plutôt que la longueur en octets. La désactivation des en-têtes de longueur du contenu a résolu le problème temporairement jusqu’à ce que je puisse réparer le système de modèles de back-end.

Je suis désolé de le dire, je n’ai pas de réponse précise pour vous. Mais j’ai aussi rencontré ce problème et, du moins dans mon cas, j’ai trouvé un moyen de contourner le problème. Alors peut-être que cela offrira des indices à quelqu’un d’autre qui connaît mieux Php sous le capot.

Le scénario est que j’ai un tableau passé à une fonction. Le contenu de ce tableau est utilisé pour produire une chaîne HTML à renvoyer au navigateur, en le plaçant entièrement dans une variable globale qui sera imprimée ultérieurement. (Cette fonction ne renvoie rien en fait. Sloppy, je le sais, mais c’est à côté du point.) À l’intérieur de ce tableau, il y a, entre autres, quelques éléments portant, par référence, des tableaux associatifs nesteds définis en dehors de cette fonction. . En procédant par élimination, j’ai constaté que la manipulation de tout élément à l’intérieur de ce tableau dans cette fonction, référencée ou non, y compris une tentative de désélection de ces éléments, entraînait une erreur net :: ERR_INCOMPLETE_CHUNKED_ENCODING et aucun contenu. Ceci en dépit du fait que la chaîne HTML dans la variable globale est exactement ce qu’elle devrait être.

Ce n’est qu’en réoutinant le script pour ne pas appliquer de références aux éléments du tableau que les choses ont recommencé à fonctionner normalement. Je soupçonne que c’est en fait un bug de PHP ayant quelque chose à voir avec la présence des éléments référencés rejetant les en-têtes de longueur de contenu, mais je n’en sais vraiment pas assez pour le dire avec certitude.

J’ai eu ce problème avec un site dans Chrome et Firefox. Si j’ai éteint le bouclier Web Avast, il est parti. Je semble avoir réussi à le faire fonctionner avec le Web Shield en ajoutant une partie du htaccess html5 à mon fichier 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  

Dans mon cas, j’ai eu /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied) ce qui a probablement causé l’erreur Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

J’ai dû supprimer /usr/local/var/run/nginx/ et laisser nginx le créer à nouveau.

 $ 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 

Je voulais juste partager mon expérience avec vous si quelqu’un a le même problème avec MOODLE .

Notre plate-forme moodle était soudainement très lente, le tableau de bord prenait environ 2 à 3 fois plus de temps à charger (jusqu’à 6 secondes) puis de temps en temps certaines pages n’étaient pas chargées du tout (pas une erreur 404 mais une page blanche) ). Dans la console des outils de développement, l’erreur suivante était visible: net::ERR_INCOMPLETE_CHUNKED_ENCODING.

À la recherche de cette erreur, il semble que Chrome soit le problème, mais nous avons eu le problème avec différents navigateurs. Après des heures de recherche et en comparant les bases de données des jours précédant la découverte du problème, quelqu’un a activé la surveillance des événements. Cependant, dans le journal “Changements de configuration”, cette modification n’était pas visible! L’activation de la surveillance des événements a finalement résolu le problème – nous n’avions aucune règle définie pour la surveillance des événements.

Nous exécutons Moodle 3.1.2+ avec MariaDB et PHP 5.4.

Mon correctif est:

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

J’espère que cela aidera quelqu’un à l’avenir, et dans mon cas, il s’agit d’un problème de Kaspersky, mais le correctif ci-dessus fonctionne très bien 🙂

Dans mon cas, cela se produisait lors de la sérialisation json d’une charge utile de retour web api – j’avais une référence “circulaire” dans mon modèle Entity Framework, je retournais un simple graphique d’object un-à-plusieurs mais l’enfant avait une référence à le parent, qui apparemment le sérialiseur de json n’aime pas. La suppression de la propriété sur l’enfant qui faisait référence au parent a fait l’affaire.

J’espère que cela aidera quelqu’un qui pourrait avoir un problème similaire.

Bien. Il n’y a pas longtemps, j’ai aussi rencontré cette question. Et enfin, j’obtiens les solutions qui répondent vraiment à ce problème.

Les symptômes de mon problème sont également les pages qui ne se chargent pas et les données json ont été tronquées de manière aléatoire.

Voici les solutions que je résume pourraient aider à résoudre ce problème

 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  5.Check your nginx fastcgi buffer is right 6.Check your nginx gzip is open 

S’il existe une boucle ou un élément qui n’existe pas, vous êtes confronté à ce problème.

Lors de l’exécution de l’application sur Chrome, la page est vide et ne répond plus.

Début du scénario:

Environnement de développement: MAC, STS 3.7.3, tc Pivotal Server 3.1, Spring MVC Web,

dans $ {myObj.getfName ()}

Fin du scénario:

Raison du problème: la fonction getfName () n’est pas définie sur myObj.

J’espère que cela vous aidera.

Je suppose que le serveur ne gère pas correctement le codage de transfert en blocs. Il doit mettre en place des fichiers fragmentés avec un bloc terminal pour indiquer que le fichier entier a été transféré. Le code ci-dessous peut donc fonctionner:

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

Dans mon cas, il était cassé config pour l’extension php mysqlnd_ms sur le serveur. Ce qui est drôle, c’est que cela fonctionnait bien sur des demandes de courte durée. Il y avait un avertissement dans le journal des erreurs du serveur, donc nous l’avons résolu rapidement.

Cela semble être un problème commun avec de multiples causes et solutions, je vais donc donner ma réponse à quiconque en aura besoin.

Je net::ERR_INCOMPLETE_CHUNKED_ENCODING sur Chrome, osx, php70, httpd24, mais le même code fonctionnait bien sur le serveur de production.

Au départ, je tenais les journaux de bord régulièrement, mais rien ne s’avérait vraiment. Un quick ls -later montré que system.log était le dernier fichier touché dans /var/log , et tailing qui m’a donné

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

Contenu dans:

 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 

Un brew uninstall php70-mongodb et un httpd -k restart plus tard et tout se passe bien.

Dans mon cas, il s’agissait de HTML. Il y avait ‘\ n’ dans la réponse json à l’origine du problème. Donc j’ai enlevé ça.

Fascinant de voir combien il y a de causes différentes pour ce problème!

Beaucoup disent que c’est un problème de Chrome, alors j’ai essayé Safari et j’ai toujours eu des problèmes. Puis essayé toutes les solutions dans ce fil, y compris la désactivation de ma protection en temps réel AVG, pas de chance.

Pour moi, le problème était mon fichier .htaccess . Tout ce qu’il contenait était FallbackResource index.php , mais quand je l’ai renommé en htaccess.txt , mon problème a été résolu.

Je net::ERR_INCOMPLETE_CHUNKED_ENCODING , après un net::ERR_INCOMPLETE_CHUNKED_ENCODING plus approfondi de l’erreur du serveur, j’ai constaté que cela était dû au délai d’exécution du script PHP.

L’ajout de cette ligne au-dessus du script PHP l’a résolu pour moi:

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

Ref: Erreur fatale: durée d’exécution maximale de 30 secondes dépassée

Hmmm je suis juste tombé sur un problème similaire mais avec des raisons différentes derrière …

J’utilise Laravel Valet sur un projet PHP vanille avec Laravel Mix . Lorsque j’ai ouvert le site dans Chrome, il y avait net::ERR_INCOMPLETE_CHUNKED_ENCODING erreurs net::ERR_INCOMPLETE_CHUNKED_ENCODING . (Si le site était chargé sur le protocole HTTPS, l’erreur est passée à net::ERR_SPDY_PROTOCOL_ERROR .)

J’ai vérifié le php.ini et opcache n’était pas activé. J’ai trouvé que dans mon cas, le problème était lié au contrôle de version des fichiers d’actifs – pour une raison quelconque, il ne semblait pas aimer une chaîne de requête dans l’URL des actifs (eh bien, curieusement, juste un en particulier?).

J’ai supprimé mix.version() pour l’environnement local et le site se charge très bien dans mon Chrome sur les protocoles HTTP et HTTPS.

Dans le contexte d’un contrôleur dans Drupal 8 (Symfony Framework), cette solution a fonctionné pour moi:

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

Sinon, l’en-tête de réponse “Transfer-Encoding” a une valeur “fragmentée”. Cela peut être un problème pour le navigateur Chrome.

J’ai eu ce problème (montrant ERR_INCOMPLETE_CHUNKED_ENCODING dans Chrome, rien dans les autres navigateurs). Il s’est avéré que le problème était que mon hébergeur GoDaddy ajoutait un script de surveillance à la fin de ma sortie.

https://www.godaddy.com/community/cPanel-Hosting/how-to-remove-additional-quot-monitoring-quot-script-added/td-p/62592