Erreur Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING

Depuis deux mois, je reçois l'erreur suivante sur la console développeur 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 notre serveur Apache interne. Cela n'arrive à personne d'autre - c'est-à-dire qu'aucun de nos utilisateurs ne rencontre ce problème - ni à personne d'autre dans 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 exactement la même chose se produit. Fichiers tronqués et autres. 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

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 à déterminer s'il s'agissait ou non d'un problème côté client. Si je vais dans 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 il revient.

D'ACCORD. J'ai testé cela trois fois et je suis sûr à 100% qu'il est causé par mon antivirus (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 apparaisse en moins d'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 est le même.

Mise à jour: je suis tombé sur 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é et le problème a disparu. ie Ce problème ne semble pas être limité à ESET.

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

Apparemment, il peut s'agir d'un problème connu affectant quelques versions de Chrome. Pour autant que je sache, c'est un problème de ces versions qui sont extrêmement sensibles à la longueur du contenu du morceau envoyé et à la taille exprimée de ce morceau (je pourrais être loin de celui-là). En bref, un problème d'en-têtes légèrement imparfait.

D'un autre côté, il se peut que le serveur n'envoie pas le bloc 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 pourquoi cela pourrait arriver.

Voici la réponse paranoïaque des programmeurs:

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

Dans votre cas, il peut s'agir d'un cas d'expiration du délai du script. 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 tester cela en prolongeant 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).

• https://code.google.com/p/chromium/issues/detail?id=461213
• IIS et Chrome: échec du chargement de la ressource: net :: ERR_INCOMPLETE_CHUNKED_ENCODING
• https://wordpress.org/support/topic/interface-issue-err_incomplete_chunked_encoding

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) effectuait la mise en mémoire tampon de la sortie . J'imagine que la sortie était trop mal découpé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 manière récursive jusqu'à ce que PHP, à juste titre, abandonne. Ainsi, le serveur n'a pas envoyé le bloc terminal de longueur 0 - ce qui était le problème que j'ai identifié plus tôt.

J'ai eu ce problème. Je l'ai retrouvé 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/nginxet plus spécifiquement le /var/lib/nginx/tmprépertoire é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 <host_name>.error_logpour voir si vous rencontrez des problèmes d'autorisation.

Pour résoudre le problème, assurez-vous que le propriétaire et le groupe de /var/lib/nginxet 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 résolu 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 ensuite, j'ai remarqué un problème sur un autre PC Linux sans antivirus. Aucune erreur dans les journaux nginx. Mon a uwsgimontré quelque chose sur "tuyau cassé" mais pas sur toutes les demandes. Tu sais quoi? Il ne restait plus d'espace sur l'appareil, ce que j'ai trouvé lors du redémarrage du serveur sur le journal de la base de données et que j'ai dfapprouvé. 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 devrait vérifier chaque demande), mais un navigateur avec un comportement étrange peut simplement ignorer les mauvaises réponses et afficher les réponses mises en cache.

Dans mon cas, j'avais /usr/local/var/run/nginx/fastcgi_temp/3/07/0000000073" failed (13: Permission denied)ce qui résultait probablement de l'erreur Chrome net :: ERR_INCOMPLETE_CHUNKED_ENCODING.

J'ai dû le 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

C'est un problème connu de 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 juste dans Chrome.

Définition de l'en- Content-Encodingtête pour identityrésoudre ce problème pour moi.

de developer.mozilla.org

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

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

J'ai juste regardé avoir un problème similaire. Et j'ai 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 de savoir comment l'en-tête Content-Length était calculé. Le backend sous-jacent calculait la longueur des caractères plutôt que la longueur des octets. La désactivation des en-têtes de longueur de contenu a résolu le problème temporairement jusqu'à ce que je puisse réparer le système de modèles d'arrière-plan.

La solution la plus simple consiste à augmenter le proxy_read_timeout pour votre emplacement proxy défini à une valeur plus élevée (disons 120s) dans votre nginx.conf.

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

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

Quand j'ai fait face à cette erreur (en faisant un appel AJAX à partir de javascript); la raison était que la réponse du contrôleur était erronée; il retournait un JSON qui n'était pas de format valide.

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

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

Je voulais juste partager mon expérience avec vous si quelqu'un pouvait 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 à se charger (jusqu'à 6 secondes) que d'habitude et de temps en temps certaines pages ne se chargeaient pas du tout (pas une erreur 404 mais une page vierge ). Dans la Developer Tools Console, l'erreur suivante était visible:net::ERR_INCOMPLETE_CHUNKED_ENCODING.

En recherchant cette erreur, il semble que Chrome soit 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 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", ce changement n'était pas visible! La désactivation 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 utilisons Moodle 3.1.2+ avec MariaDB et PHP 5.4.

Cela se produisait 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 pendant cette période sans problème.

Pour ces clients, cela se produisait principalement sur des scripts PHP qui avaient du HTML en streaming - c'est-à-dire des pages «Connexion: fermer» où la sortie était envoyée au navigateur lorsque la sortie devenait disponible.

Il s'est avéré que la connexion entre le processus PHP et le serveur Web tombait prématurément, avant la fin du script et bien avant tout délai d'expiration.

Le problème était opcache.fast_shutdown = 1 dans le fichier principal php.ini. Cette directive est désactivée par défaut, mais il semble que certains administrateurs de serveur pensent qu'il y a une amélioration des performances 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, cela a entraîné une exécution plus lente de certains scripts et un bilan horrible de parfois entrer dans l'arrêt alors que le script est toujours en cours d'exécution, ou même à la fin de l'exécution alors que le serveur Web est toujours en train de lire à partir du tampon. Il existe un ancien 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 en raison de cette ERR_INCOMPLETE_CHUNKED_ENCODING ERR_SPDY_PROTOCOL_ERROR Parfois, il y a des segfaults corrélatifs enregistrés; parfois non.

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

Je suis désolé de dire que je n'ai pas de réponse précise pour vous. Mais j'ai également rencontré ce problème et, du moins dans mon cas, j'ai trouvé un moyen de le contourner. Alors peut-être que cela offrira 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 plaçant le tout dans une variable globale qui sera imprimée ultérieurement. (Cette fonction ne renvoie rien en fait. 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 trouvé que la manipulation de tout élément à l'intérieur de ce tableau au sein de cette fonction, référencé ou non, y compris une tentative de désarmer ces éléments référencés, entraîne Chrome lançant une erreur net :: ERR_INCOMPLETE_CHUNKED_ENCODING et n'affichant aucun contenu.

Ce n'est qu'en ré-outillant le script pour ne pas appliquer les références aux éléments du tableau en premier lieu que les choses ont recommencé à fonctionner normalement. Je soupçonne qu'il s'agit en fait d'un bogue 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 être sûr.

J'ai eu ce problème avec un site sous Chrome et Firefox. Si j'ai désactivé Avast Web Shield, il a disparu. Il me semble avoir réussi à le faire fonctionner avec le Web Shield en cours d'exécution en ajoutant une partie du htaccess standard 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.

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

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 avec 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 d'une API Web - j'avais une référence `` circulaire '' dans mon modèle Entity Framework, je renvoyais un simple graphique d'objet un-à-plusieurs mais l'enfant avait une référence à le parent, ce que le sérialiseur json n'aime apparemment 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.

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

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

J'obtenais net::ERR_INCOMPLETE_CHUNKED_ENCODING, en examinant de plus près les journaux d'erreurs du serveur, j'ai trouvé 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

Réf: Erreur fatale: Temps d'exécution maximum de 30 secondes dépassé

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

cela m'arrivait pour une raison totalement différente. net :: ERR_INCOMPLETE_CHUNKED_ENCODING 200 lorsque j'inspecte la page et que je vais à l'onglet newtork, je vois que la page vendor.js n'a pas pu se charger. Après vérification, il semble que la taille du fichier js est grande ~ 6,5 Mo. C'est quand j'ai réalisé que j'avais besoin de compresser le fichier js. J'ai vérifié que j'utilisais la ng buildcommande pour construire. Au lieu de cela, quand je l'ai utilisé, ng build --prod --aot --vendor-chunk --common-chunk --delete-output-path --buildOptimizercela a fonctionné pour moi.Voir https://github.com/angular/angular-cli/issues/9016

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

Mes symptômes de problème sont également les pages qui ne se chargent pas et trouvent que les données json ont été tronquées au hasard.

Voici les solutions que je résume qui 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
  <?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, vous rencontrez 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 fragmenté. Il doit terminer un fichier fragmenté 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, la configuration de l'extension php mysqlnd_ms était cassée sur le serveur. Le plus drôle est que cela fonctionnait bien sur les demandes de courte durée. Il y avait un avertissement dans le journal des erreurs du serveur, nous l'avons donc corrigé rapidement.

Cela semble être un problème courant avec plusieurs causes et solutions, je vais donc mettre ma réponse ici pour tous ceux qui pourraient en avoir besoin.

J'avais une net::ERR_INCOMPLETE_CHUNKED_ENCODINGcombinaison Chrome, osx, php70, httpd24, mais le même code fonctionnait bien sur le serveur de production.

J'ai d'abord suivi les journaux réguliers mais rien ne s'est vraiment manifesté. Une ls -laterprésentation rapide system.logétait le dernier fichier touché /var/log, et le suivi 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-mongodbet un httpd -k restartplus tard et tout était en douceur.

Dans mon cas, c'était une question de html. Il y avait '\ n' dans la réponse json à l'origine du problème. Alors j'ai enlevé ça.

C'est fascinant de voir le nombre de causes différentes à ce problème!

Beaucoup disent que c'est un problème de Chrome, j'ai donc essayé Safari et j'avais toujours des problèmes. J'ai ensuite essayé toutes les solutions de 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 .htaccessdossier. Tout ce qu'il contenait était FallbackResource index.php, mais lorsque je l'ai renommé htaccess.txt, mon problème a été résolu.

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 générait des net::ERR_INCOMPLETE_CHUNKED_ENCODINGerreurs. (Si j'avais le site chargé sur le protocole HTTPS, l'erreur est devenue net::ERR_SPDY_PROTOCOL_ERROR.)

J'ai vérifié le php.inietopcache n'a pas été activé. J'ai trouvé que dans mon cas, le problème était lié à la gestion des versions des fichiers d'actifs - pour une raison quelconque, il ne semblait pas aimer une chaîne de requête dans l'URL des actifs (enfin, 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 Controller 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 le navigateur Chrome.