php - Erreur Chrome net:: ERR_INCOMPLETE_CHUNKED_ENCODING




webpack net:: err_incomplete_chunked_encoding (20)

Depuis deux mois, le message d'erreur suivant s'affiche sur la console de développement de Chrome:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Symptômes:

  • Les pages ne se chargent pas.
  • Fichiers CSS et JS tronqués.
  • Pages suspendues.

Environnement serveur:

  • Apache 2.2.22
  • PHP
  • Ubuntu

Cela m’arrive sur mon serveur Apache interne. Cela n'arrive à personne d'autre - aucun de nos utilisateurs ne rencontre ce problème - ni à aucun autre membre de notre équipe de développement.

D'autres personnes accèdent exactement au même serveur avec exactement 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 tout le reste. La seule chose à faire 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

Lors des tests, 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 sur HTTP 1.1 n'est pas une solution appropriée.

Mise à jour : Étant donné que je suis le seul à rencontrer 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 j'utilise les paramètres de Chrome et que j'utilise l'option "Restaurer les paramètres par défaut", le problème disparaîtra pendant environ 10 à 20 minutes. Puis ça revient.


Bien. Il n'y a pas longtemps, j'ai également rencontré cette question. Et enfin, je trouve les solutions qui résolvent vraiment ce problème.

Mes problèmes de problèmes sont également les pages ne se chargeant pas et trouver les données JSON a été tronqué de manière aléatoire.

Voici les solutions que je résume pourrait 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
  <?php
     header('Content-length: ' . strlen($output));
  ?>
5.Check your nginx fastcgi buffer is right 
6.Check your nginx gzip is open

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 le corrigea également:

.htaccess:

php_value opcache.enable 0

Cela semble être un problème courant avec de multiples causes et solutions, je vais donc donner ma réponse ici à toute personne qui pourrait en avoir besoin.

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

J'ai initialement suivi les journaux réguliers, mais rien ne s'est vraiment présenté. Un peu plus ls -later montré que system.log était le dernier fichier touché dans /var/log , et que cela 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

Une brew uninstall php70-mongodb et un httpd -k restart plus tard et tout allait bien.


D'ACCORD. J'ai effectué un triple test et je suis à 100% sûr que cela est dû à 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 rallumé, mais le problème a refait surface en une minute.

Au cours des dernières 24 heures, j'ai activé et désactivé la protection en temps réel, pour en être sûr. A chaque fois, le résultat est 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 anti-virus Kaspersky. Il l'a désactivé et le problème est parti. C'est-à-dire que ce problème ne semble pas être limité à ESET.


Dans mon cas, cela se produisait lors de la sérialisation json d'une charge utile de retour d'api web - j'avais une référence "circulaire" dans mon modèle Entity Framework, je retournais un simple graphe d'objet un-à-plusieurs, mais l'enfant avait une référence à le parent, qui apparemment le sérialiseur JSON n'aime pas. Supprimer 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.


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


Dans mon cas, je rencontrais /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied) ce qui entraînait probablement 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

Fascinant de voir le nombre de causes différentes de ce problème!

Beaucoup disent que c'est un problème lié à Chrome. J'ai donc essayé Safari et je rencontrais toujours des problèmes. Vous avez ensuite essayé toutes les solutions de ce fil, y compris l’arrêt de la protection en temps réel AVG, sans succès.

Pour moi, le problème était mon fichier .htaccess . FallbackResource index.php ne contenait que celui-ci, mais lorsque je l'ai renommé htaccess.txt , mon problème a été résolu.


Ici, le problème était mon AV AVAST. Dès que je l'ai désactivé, le problème avait disparu.

Mais j'aimerais vraiment comprendre la cause de ce comportement.


Il est connu problème de Chrome. Selon Chrome et Chromium, il n’existe pas de solution universelle à ce problème. Ce problème n'est pas lié au type et à la version du serveur, il est exact dans Chrome.

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

de developer.mozilla.org

identité | Indique la fonction d'identité (c'est-à-dire pas de compression, ni modification).

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


J'ai eu ce problème avec un site sur Chrome et Firefox. Si j'ai désactivé le bouclier Web Avast, il est parti. Il semble que j'ai réussi à le faire fonctionner avec le bouclier Web en ajoutant quelques-uns des html5 du type html5 à mon fichier htaccess:

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

ob_flush();

?>

J'ai eu ce problème. Je l'ai retrouvé après avoir essayé la plupart des autres réponses à cette question. Cela était dû au propriétaire et aux autorisations du répertoire /var/lib/nginx et plus précisément du /var/lib/nginx/tmp , qui étaient incorrects.

Fast-cgi utilise le répertoire tmp 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 volumineuse.

Consultez le nginx <host_name>.error_log pour savoir si vous rencontrez des problèmes d'autorisation.

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


Je suis désolé de dire que je n'ai pas de réponse précise à vous donner. Mais j'ai aussi rencontré ce problème et, du moins dans mon cas, j'ai trouvé un moyen de le contourner. Alors peut-être que ça va donner des indices à quelqu'un d'autre qui en sait plus sur Php sous le capot.

Le scénario est, j'ai un tableau passé à une fonction. Le contenu de ce tableau est utilisé pour produire une chaîne HTML à renvoyer au navigateur, en la plaçant entièrement dans une variable globale imprimée ultérieurement. (Cette fonction ne renvoie rien en réalité. Sloppy, je sais, mais ce n'est pas la question.) À l'intérieur de ce tableau, entre autres, se trouvent quelques éléments portant, par référence, des tableaux associatifs imbriqués qui ont été définis en dehors de cette fonction. . Par processus d’élimination, j’ai constaté que la manipulation de tout élément de ce tableau au sein de cette fonction, référencée ou non, y compris une tentative de suppression de ces éléments référencés, avait pour conséquence que Chrome renvoyait une erreur net :: ERR_INCOMPLETE_CHUNKED_ENCODING sans afficher de 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é-outillant le script de ne pas appliquer de références aux éléments du tableau que tout a commencé à fonctionner normalement. Je soupçonne qu’il s’agit en fait d’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 à ce sujet pour en être certain.


Je suppose que le serveur ne gère pas correctement l'encodage de transfert fragmenté. Il doit mettre les fichiers fragmentés avec un bloc terminal pour indiquer que le fichier entier a été transféré. Pour que le code ci-dessous fonctionne:

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

L'erreur est d'essayer 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 peut-être d’un problème connu ayant un impact sur quelques versions de Chrome. Autant que je sache, le problème est que ces versions sont extrêmement sensibles à la longueur du contenu du bloc envoyé et à la taille exprimée de ce dernier (je pourrais en être très éloigné). En bref, un problème d'en-têtes légèrement imparfait.

D'autre part, il se peut que le serveur n'envoie pas le bloc de longueur 0 du terminal. Ce qui pourrait être ob_flush(); avec ob_flush(); . Il est également possible que Chrome (ou la connexion ou quelque chose) soit lent. Ainsi, 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:

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

Dans votre cas, il se peut que le script arrive à expiration. Je ne sais pas vraiment pourquoi cela ne devrait affecter que vous, mais cela pourrait être dû à un tas de conditions de course? C'est une supposition totale. Vous devriez pouvoir le tester en allongeant le temps d'exécution du script.

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

Cela peut également être aussi simple que vous devez mettre à jour votre installation de Chrome (car ce problème est spécifique à Chrome).

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

Concrètement, mon code s’appelait accidentellement jusqu’à ce que PHP, à juste titre, abandonne. Ainsi, le serveur n’a pas envoyé le bloc de terminal de longueur 0, ce qui était le problème que j’avais identifié précédemment.


La solution la plus simple consiste à augmenter la valeur de proxy_read_timeout de votre emplacement de proxy défini (soit environ 120 secondes) dans votre 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>

J'ai trouvé cette solution ici https://rijulaggarwal.wordpress.com/2018/01/10/atmosphere-long-polling-on-nginx-chunked-encoding-error/


OMG, j'ai eu le même problème il y a 5 minutes. J'ai passé plusieurs heures à trouver une solution. À première vue, la désactivation de l'antivirus a résolu le problème sous Windows. Mais ensuite, j'ai remarqué un problème sur un autre ordinateur Linux sans antivirus. Aucune erreur dans les journaux nginx. Mon uwsgi montré quelque chose à propos de "tuyau cassé" mais pas pour toutes les demandes. Savoir quoi? Il ne restait plus d’espace libre sur le périphérique, ce que j’ai trouvé lors du redémarrage du serveur sur le journal de la base de données, et df approuvé. La seule explication sur la raison pour laquelle l'antivirus a été résolu est qu'il empêche la mise en cache du navigateur (il devrait vérifier chaque demande), mais un navigateur avec un comportement étrange peut simplement ignorer les réponses incorrectes et afficher les réponses en cache.


Pour moi, cela était dû à un espace libre insuffisant sur le disque dur.


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

Lorsque vous exécutez 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 de l'émission: la fonction getfName () n'est pas définie sur myObj.

J'espère que ça vous aidera.


Vérifiez l’autorisation du dossier nginx et définissez l’autorisation appache pour cela:

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




chunked