Depuis deux mois, je reçois l'erreur suivante dans la console du développeur de Chrome :
net::ERR_INCOMPLETE_CHUNKED_ENCODING
Symptômes :
Environnement du serveur :
Ce problème 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 - ni aucun membre 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 résultat.
J'ai utilisé Firefox et la même chose s'est produite. Fichiers tronqués et autres. Le seul problème est que Firefox ne génère aucune erreur de console. Il faut donc inspecter la requête HTTP via Firebug pour détecter 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
Lors de mes tests, j'ai pu résoudre le problème en forçant HTTP 1.0 dans mon fichier htaccess :
SetEnv downgrade-1.0
Cela permet de se débarrasser du problème. Cependant, forcer HTTP 1.0 sur HTTP 1.1 n'est pas une bonne solution.
Mise à jour : Comme je suis le seul à rencontrer ce problème, je me suis dit que je devais passer plus de temps à vérifier s'il s'agissait ou non d'un problème côté client. Si j'entre dans les paramètres de Chrome et que j'utilise l'option " Restaurer par défaut ", le problème disparaît pendant environ 10 à 20 minutes. Puis il revient.
OK. J'ai testé trois fois ce problème et je suis 100% sûr 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 laissé la protection en temps réel désactivée pendant 6-7 heures et le problème ne s'est jamais produit.
Il y a quelques instants, je l'ai réactivée, mais le problème est réapparu dans la minute qui a suivi.
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 de son antivirus Kaspersky. Il l'a désactivée et le problème a disparu. Ce problème ne semble pas être limité à 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, il s'agit d'un problème connu qui touche quelques versions de Chrome. D'après ce que je sais, ces versions sont extrêmement sensibles à la longueur du contenu du morceau envoyé et à la taille exprimée de ce morceau (je peux me tromper). En bref, un problème d'en-têtes légèrement imparfaits.
D'un autre côté, il se peut que le serveur n'envoie pas le chunk terminal de longueur 0. Ce qui pourrait être réparable avec ob_flush();
. Il est également possible que Chrome (ou la connexion ou autre) soit lent. Ainsi, lorsque la connexion est fermée, la page n'est pas encore chargée. Je n'ai aucune idée de la raison pour laquelle cela peut se produire.
Voici la réponse du programmeur paranoïaque :
<?php
// ... your code
flush();
ob_flush();
sleep(2);
exit(0);
?>
Dans votre cas, il pourrait s'agir d'un problème de timing du script. Je ne sais pas vraiment pourquoi cela n'affecte que vous, mais cela pourrait être dû à un ensemble de conditions de course ? Ce n'est qu'une supposition. Vous devriez pouvoir tester cela en prolongeant le temps d'exécution du script.
<?php
// ... your while code
set_time_limit(30);
// ... more while code
?>
Il se peut aussi que vous deviez simplement mettre à jour votre installation de Chrome (car ce problème est spécifique à Chrome).
MISE À JOUR: J'ai pu reproduire cette erreur (enfin) lorsqu'une erreur fatale est survenue alors que PHP (sur le même hôte local) était en train de [bufferiser la sortie][1]. J'imagine que la sortie était trop malmenée pour être utile (en-têtes mais peu ou pas de contenu).
Plus précisément, mon code s'est accidentellement appelé lui-même de manière récursive jusqu'à ce que PHP, à juste titre, abandonne. Ainsi, le serveur n'a pas envoyé le chunk terminal de longueur 0 - ce qui était le problème que j'ai identifié plus tôt.
[1] : https://stackoverflow.com/questions/4401949/whats-the-use-of-ob-start-in-php
Ce qui suit devrait régler le problème pour tous les clients.
<?php
//Gather output (if it is not already in a variable, use ob_start() and ob_get_clean() )
// Before sending output:
header('Content-length: ' . strlen($output));
Mais dans mon cas, la solution suivante était une meilleure option et a également permis de résoudre le problème :
.htaccess :
php_value opcache.enable 0