Chrome net:: ERR INCOMPLETE chunked erreur D'encodage
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.
- les Pages de la pendaison.
environnement serveur:
cela m'arrive sur notre serveur Apache interne. Cela n'arrive à personne d'autre - i.e. aucun de nos utilisateurs ne connaît ce problème - ni personne d'autre dans notre équipe de développement.
D'autres personnes accèdent au même serveur avec la même version exacte de Chrome. J'ai également essayé de désactiver toutes les extensions et la navigation en mode Incognito - sans aucun effet.
j'ai utilisé Firefox et la même chose se produit. Des fichiers tronqués et tout. 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
pendant les tests, j'ai pu corriger le problème en forçant HTTP 1.0 dans mon fichier htaccess:
SetEnv downgrade-1.0
ceci élimine le problème. Cependant, forcer HTTP 1.0 sur HTTP 1.1 n'est pas une bonne solution.
mise à jour : parce que je suis le seul à faire l'expérience de ce problème, j'ai pensé que je devais passer plus de temps à examiner si oui ou non il s'agissait d'un problème côté client. Si je vais dans les paramètres de Chrome et que j'utilise l'option "Restore to Default", le problème disparaîtra pendant environ 10-20 minutes. Puis il retourne.
26 réponses
OK. J'ai Triple-testé cela 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 rallumé, seulement pour que le problème refasse surface en une minute.
sur le parcours au cours des dernières 24 heures, j'ai activé et désactivé la protection en temps réel, 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 antivirus Kaspersky. Il désactivé et le problème a disparu. Ce problème ne semble pas être limitée à ESET.
l'erreur est d'essayer de dire que Chrome a été coupé pendant que la page était envoyée. Votre problème est d'essayer de comprendre pourquoi.
apparemment, cela pourrait être un problème connu impactant quelques versions de Chrome. Pour autant que je puisse dire c'est une question de ces versions étant massivement sensible à la longueur du contenu du morceau étant envoyé et la taille exprimée de ce morceau (je pourrais être loin sur celui-ci). En bref une question de headers légèrement imparfaite.
d'un autre côté, il se peut que le serveur n'envoie pas le morceau de 0 Longueur du terminal. Qui pourrait être fixe avec ob_flush();
. Il est également possible que le Chrome (ou la connexion ou quelque chose) soit lent de sorte que lorsque la connexion est fermée, la page n'est pas encore chargée. Je ne sais pas pourquoi ça pourrait arriver.
Voici la réponse des programmeurs paranoïaques:
<?php
// ... your code
flush();
ob_flush();
sleep(2);
exit(0);
?>
dans votre cas, c'est peut-être un cas de synchronisation du script. Je ne suis pas vraiment pourquoi il devrait en effet seulement vous, mais il pourrait être fait à tout un tas de conditions de course? C'est une véritable deviner. 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 peut également être aussi simple que vous avez besoin de mettre à jour votre installation Chrome (car ce problème est spécifique à Chrome).
- https://code.google.com/p/chromium/issues/detail?id=461213
- IIS & Chrome: pas de charge resource: net:: ERR_INCOMPLETE_CHUNKED_ENCODING
- https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding
UPDATE: j'ai pu répliquer cette erreur (enfin) quand une erreur fatale a été lancée alors que PHP (sur le même localhost) était tampon de sortie . J'imagine que le la production était trop malmenée pour être d'une grande utilité (en-têtes mais peu ou pas de contenu).
plus précisément, j'ai accidentellement fait appeler mon code de façon récursive jusqu'à ce que PHP, à juste titre, abandonne. Ainsi, le serveur n'a pas envoyé le terminal 0 Longueur morceau-qui était le problème que j'ai identifié plus tôt.
j'ai eu ce problème. Je l'ai trouvé après avoir essayé la plupart des autres réponses à cette question. Il a été causé par le propriétaire et les permissions du /var/lib/nginx
et plus précisément le /var/lib/nginx/tmp
répertoire étant incorrect.
le répertoire tmp est utilisé par fast-cgi pour mettre en cache les réponses au fur et à mesure qu'elles sont générées, mais seulement si elles sont supérieures à une certaine taille. Donc, la question est intermittente, et ne se produit que lorsque la réponse générée est importante.
Vérifiez le nginx <host_name>.error_log
pour voir si vous avez des problèmes de permission.
pour fixer, s'assurer que le propriétaire et le groupe de /var/lib/nginx
et tous les sous-DIR est nginx.
ce qui suit devrait le corriger 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 corrigé aussi bien:
.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. À première vue, la désactivation de l'antivirus a résolu le problème sur Windows. Mais j'ai remarqué un problème sur d'autres PC linux sans antivirus. Aucune erreur dans les logs de nginx. Mon uwsgi
montrait quelque chose à propos de "pipe cassée" mais pas sur toutes les demandes.
Savez quoi? Il n'y avait plus d'espace sur l'appareil, que j'ai trouvé lorsque le serveur redémarré dans le journal de la base de données, et df
l'a approuvé. Seule explication sur la raison pour laquelle l'antivirus a été résolu cela est qu'il empêche la mise en cache du navigateur (il devrait vérifier chaque demande), mais navigateur avec un certain comportement étrange peut tout simplement ignorer mauvaise réponse et afficher des réponses mises en cache.
il est connu problème de Chrome. Selon Chrome et Chrome bug trackers 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.
Réglage Content-Encoding
en-tête identity
résolu ce problème pour moi.
identity / indique la fonction identity (i.e. pas de compression, ni modification.)
donc, je peux suggérer, que dans certains cas Chrome ne peut pas effectuer compresse gzip correctement.
ici le problème était mon Avast AV. Dès que je l'ai désactivé, le problème a disparu.
mais, je voudrais vraiment comprendre la cause de ce comportement.
dans mon cas, j'avais /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)
, ce qui a probablement causé L'erreur de codage Chrome net::ERR_INCOMPLETE_CHUNKED_ENCODE.
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
cela se passait sur deux serveurs de clients différents séparés par plusieurs années, en utilisant le même code qui a été déployé sur des centaines d'autres serveurs pour cette période sans problème.
pour ces clients, il s'est produit la plupart du temps sur des scripts PHP qui ont streaming HTML - c'est-à-dire, "connexion: fermer" pages où la sortie a été envoyée au navigateur que la sortie est devenue disponible.
il s'est avéré que la connexion entre le processus PHP et le web le serveur tombait prématurément, avant que le script ne soit terminé et bien avant toute temporisation.
le problème était opcache.fast_shutdown = 1 dans le php principal.fichier ini. Cette directive est désactivée par défaut, mais il semble que certains administrateurs de serveurs pensent qu'il y a un boost de performance à avoir ici. Dans tous mes tests, je n'ai jamais noté de différence positive en utilisant ce réglage. Dans mon expérience, il a causé quelques scripts à exécuter plus lentement, et a une piste terrible enregistrement de la saisie de shutdown pendant que le script est encore en cours d'exécution, ou même à la fin de l'exécution pendant que le serveur web est encore en train de lire depuis le buffer. Il y a un vieux rapport de bogue de 2013, non résolu depuis février 2017, qui peut être lié: https://github.com/zendtech/ZendOptimizerPlus/issues/146
j'ai vu les erreurs suivantes apparaître en raison de ce ERR_INCOMPLET_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Parfois il y a des corrélative segmentation connecté; parfois non.
si vous rencontrez l'un ou l'autre, vérifiez votre phpinfo, et assurez-vous opcache.fast_shutdown est désactivé.
je viens d'avoir un problème similaire. Et remarqua que cela ne se produisait que lorsque la page contenait des caractères UTF-8 avec une valeur ordinale supérieure à 255 (i.e. multibyte).
ce qui a fini par être le problème était la façon dont L'en-tête Content-Length était calculé. L'arrière-plan sous-jacent était de calculer la longueur des caractères, plutôt que la longueur des octets. Désactiver les en-têtes content-length a réglé le problème temporairement jusqu'à ce que je puisse réparer le système de gabarit de l'arrière-plan.
je suis désolé de 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 le contourner. Donc peut-être que ça offrira quelques 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 plaçant tout cela dans une variable globale qui est ensuite imprimée. (Cette fonction n'est pas de retourner quoi que ce soit. Négligent, je sais, mais ce n'est pas la question.) À l'intérieur de ce tableau, entre autres choses, il y a un couple d'é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 trouvé que la manipulation de n'importe quel élément à l'intérieur de ce tableau dans cette fonction, référencé ou non, y compris une tentative de désactiver ces éléments référencés, se traduit par Chrome lancer un net:: ERR_INCOMPLETE_CHUNKED_ENCODING error and displaying no content. C'est 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 pour ne pas appliquer de références aux éléments du tableau que les choses ont recommencé à fonctionner normalement. Je pense qu'il s'agit en fait D'un bug Php ayant quelque chose à voir avec la présence des éléments référencés jetant les en-têtes content-length, mais je ne le fais vraiment pas en savoir assez sur ce à dire pour sûr.
j'ai eu ce problème avec un site dans Chrome et Firefox. Si J'avais désactivé le Bouclier Avast, il aurait disparu. Il semble que j'ai réussi à le faire fonctionner avec le Web Shield en ajoutant du HTML5 boilerplate htaccess à 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.
<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>
je voulais juste partager mon expérience avec vous si quelqu'un pourrait avoir le même problème avec MOODLE .
notre plateforme moodle était soudainement très lente, le tableau de bord prenait environ 2 à 3 fois plus de temps à charger (jusqu'à 6 secondes) que d'habitude et de temps en temps certaines pages n'étaient pas chargées du tout (pas une erreur 404 mais une page vierge). Dans la Console Developer Tools, l'erreur suivante était visible: net::ERR_INCOMPLETE_CHUNKED_ENCODING.
À la recherche de cette erreur, il semble que Chrome est le problème, mais nous avons eu le problème avec divers navigateurs. Après des heures de recherche et de comparaison des bases de données des jours avant que j'ai finalement trouvé le problème, quelqu'un a activé la surveillance de l'événement. Cependant, dans le journal" Config changes", ce changement n'était pas visible! Désactiver la surveillance des événements, a finalement résolu le problème - nous n'avions pas de règles définies pour la surveillance des événements.
nous exécutons Moodle 3.1.2+ avec MariaDB et PHP 5.4.
Ma solution est:
<?php ob_start(); ?>
<!DOCTYPE html>
<html lang="de">
.....
....//your whole code
....
</html>
<?php
ob_clean();
ob_end_flush();
ob_flush();
?>
J'espère que cela aidera quelqu'un à l'avenir, et dans mon cas c'est un problème Kaspersky, mais la solution ci-dessus fonctionne bien:)
dans mon cas, cela se passait 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 de cadre D'entité, je retournais un simple graphique d'objet un-à-plusieurs en arrière mais l'enfant avait une référence en arrière au parent, qui apparemment le serializer json doensn n'aime pas. Enlever la propriété de l'enfant qui faisait référence au parent a fait l'affaire.
Espérons que cela aide quelqu'un qui pourrait avoir un problème similaire.
bien. Il n'y a pas longtemps, j'ai également rencontré cette question. Et finalement, j'obtiens les solutions qui abordent vraiment cette question.
mes symptômes de problème sont aussi les pages qui ne se chargent pas et trouver les données json a été tronqué au hasard.
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
S'il y a une boucle ou un élément qui n'existe pas, alors vous êtes confrontés à ce problème.
lors de L'exécution de L'application sur Chrome, la page est vide et ne répond plus.
Scénario:
Dev Environment: 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 ça vous aidera.
à mon avis, le serveur ne gère pas correctement l'encodage de transfert. Il a besoin d'un terminal pour les fichiers tronqués avec un terminal pour indiquer que le fichier entier a été transféré.Donc le code ci-dessous peut fonctionner:
echo "\n";
flush();
ob_flush();
exit(0);
dans mon cas, il a été cassé config pour mysqld_ms extension php sur le serveur. Ce qui est drôle, c'est qu'il fonctionnait très bien sur les demandes de courte durée. Il y avait un avertissement dans le journal des erreurs du serveur, nous avons donc fixé rapidement.
cela semble comme un problème commun avec des causes multiples et des solutions, donc je vais mettre ma réponse ici pour quiconque qui peut en avoir besoin.
j'obtenais net::ERR_INCOMPLETE_CHUNKED_ENCODING
sur Chrome, osx, php70, combinaison httpd24, mais le même code fonctionnait bien sur le serveur de production.
j'ai d'abord suivi les bûches régulières, mais rien n'est vraiment apparu. Un rapide ls -later
a montré system.log
était le dernier fichier touché dans /var/log
, 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, tout était de la voile en douceur.
Dans mon cas, il était question de html. Il y avait "\n " dans la réponse json causant le problème. J'ai donc enlevé.
fascinant de voir combien de causes différentes il y a pour ce numéro!
beaucoup disent que c'est un problème de Chrome, donc j'ai essayé le Safari et j'avais encore des problèmes. Puis j'ai essayé toutes les solutions dans ce fil, y compris désactiver ma protection AVG Real Time, pas de chance.
pour moi, le problème était mon dossier .htaccess
. Tout était FallbackResource index.php
, mais quand je l'ai renommé htaccess.txt
, mon problème a été résolu.
je recevais net::ERR_INCOMPLETE_CHUNKED_ENCODING
, en regardant de plus près les erreurs du serveur, j'ai trouvé que c'était dû à PHP script execution timeout.
ajouter cette ligne en plus du script PHP résolu pour moi:
ini_set('max_execution_time', 300); //300 seconds = 5 minutes
Ref: Fatal error: Maximum execution time of 30 seconds exceeded
Hmmm je viens de tomber sur une question 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 lançait des erreurs net::ERR_INCOMPLETE_CHUNKED_ENCODING
. (Si j'avais chargé le site sur protocole HTTPS, l'erreur a été changée en net::ERR_SPDY_PROTOCOL_ERROR
.)
j'ai coché php.ini
et opcache
n'était pas activé. J'ai trouvé que dans mon cas, le problème était lié à la 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, assez 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'chunked'. Cela peut être un problème pour Chrome browser.
j'ai eu ce problème (afficher ERR_INCOMPLETE_CHUNKED_ENCODING dans Chrome, rien dans les autres navigateurs). Il s'est avéré que le problème était mon hébergeur GoDaddy ajoutant un script de suivi à la fin de ma sortie.