Erreur net net Chrome :: ERR_INCOMPLETE_CHUNKED_ENCODING
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 - c’est-à-dire 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 lié au 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îtrapendant environ 10 à 20 minutes. Puis ça revient.
D'ACCORD. 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é, 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, juste pour en être sûr. A 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 est parti. C'est-à-dire que ce problème ne semble pas être limité à ESET.
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, cela pourrait être un problème connu ayant un impact sur deux 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 réparable 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, cela pourrait être un cas de délai d’exécution du script. Je ne suis pas vraiment sûr de savoir pourquoi cela ne devrait affecter que vous mais cela pourrait être fait pour 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).
- https://code.google.com/p/chromium/issues/detail?id=461213
- IIS & Chrome: échec du chargement de la ressource: 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) lorsqu'une erreur fatale a été générée alors que PHP (sur le même hôte local) était sortie en mémoire tampon . J'imagine que la sortie était trop malmenée pour être très utile (en-têtes mais peu ou pas de contenu).
Plus précisément, mon code s’appelait accidentellement 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’avais identifié précédemment.
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 /var/lib/nginx et plus précisément du répertoire /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.
Vérifiez le nginx <Host_name>.error_log pour voir 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 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 le corrigea également:
.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 sous Windows. Mais ensuite, j'ai remarqué un problème sur un autre ordinateur Linux sans antivirus. Aucune erreur dans les journaux nginx. Ma uwsgi a montré quelque chose à propos de "Pipe cassée" mais pas sur toutes les demandes . Savoir quoi? Il ne restait plus d'espace 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 que df a 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 erronées et afficher les réponses en cache.
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 Content-Encoding header sur identity m'a résolu le problème.
identité | Indique la fonction d'identité (c'est-à-dire aucune compression, ni modification ).
Donc, je peux suggérer que, dans certains cas, Chrome ne peut pas compresser gzip correctement.
Dans mon cas, j'avais /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.
Je devais 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 produisait sur deux serveurs différents, séparés par plusieurs années, en utilisant le même code qui avait été déployé sur des centaines d'autres serveurs à cette époque sans problème.
Pour ces clients, cela se produisait principalement sur les scripts PHP qui diffusaient en HTML, c'est-à-dire les pages "Connexion: fermer", dans lesquelles la sortie était envoyée au navigateur lorsque celle-ci était disponible.
Il s'est avéré que la connexion entre le processus PHP et le serveur Web avait été interrompue prématurément, avant la fin du script et bien avant la fin du délai imparti.
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 croient qu'il est possible d'améliorer les performances ici. Dans tous mes tests, je n'ai jamais noté de différence positive avec ce paramètre. D'après mon expérience, certains scripts ont en réalité été exécutés plus lentement et ont parfois fait plusieurs tentatives d'arrêt après avoir été exécutés, voire à la fin de l'exécution alors que le serveur Web lisait toujours dans la mémoire tampon. Il y a un ancien rapport de bogue de 2013, non résolu en février 2017, qui pourrait ê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, il existe 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é.
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.
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/
Ici, le problème était mon Avast AV . Dès que je l'ai désactivé, le problème avait disparu.
Mais j'aimerais vraiment comprendre la cause de ce comportement.
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.
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. Je semble avoir réussi à le faire fonctionner avec le bouclier Web en ajoutant quelques-uns des html5 du html5
# ------------------------------------------------------------------------------
# | 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 juste regardé avoir 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.-à-d. Plusieurs octets).
Ce qui a fini par être le problème était de savoir comment l’en-tête Content-Length était calculé. Le système sous-jacent était la longueur de caractère, plutôt que la longueur en octets. Le fait de désactiver les 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 gabarit d'arrière-plan.
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 le plaçant tout au sein d'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 choses, 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 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 voulais juste partager mon expérience avec vous si quelqu'un pouvait avoir le même problème avecMOODLE.
Notre plate-forme moodle a été soudainement très lente, le tableau de bord a pris environ 2-3 fois plus de temps à charger (jusqu'à 6 secondes), puis, comme d'habitude, et de temps en temps, certaines pages n'étaient pas chargées du tout (pas une erreur 404 mais une page vierge ). L'erreur suivante était visible dans la console des outils de développement: net::ERR_INCOMPLETE_CHUNKED_ENCODING.
En recherchant cette erreur, il semble que Chrome soit la cause du problème, mais nous avions le problème avec divers navigateurs. Après des heures de recherche et de comparaison des bases de données des jours qui ont précédé ma découverte du problème, quelqu'un a activé la surveillance des événements. Cependant, dans le journal "Modifications de configuration", cette modification n'était pas visible! Désactiver la surveillance des événements a finalement résolu le problème - aucune règle n’était définie pour la surveillance des événements.
Nous utilisons Moodle 3.1.2+ avec MariaDB et PHP 5.4.
Quand j'ai fait face à cette erreur (en faisant AJAX un appel javascript); la raison en était que la réponse du contrôleur était erronée; il retournait un JSON qui n'était pas au format valide.
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 de Kaspersky, mais le correctif ci-dessus fonctionne très bien :)
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.
Je recevais net::ERR_INCOMPLETE_CHUNKED_ENCODING sur la combinaison Chrome, osx, php70, httpd24, mais le même code fonctionnait bien sur le serveur de production.
Au début, je me suis contenté des bûches normales, mais rien n’est vraiment arrivé. Un ls -later rapide a montré que system.log était le dernier fichier touché dans /var/log, et le suivi qui m’a
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 s'est déroulé sans encombre.
Vérifiez l’autorisation du dossier nginx et définissez l’autorisation appache pour cela:
chown -R www-data:www-data /var/lib/nginx
Hmmm je suis tombé sur un problème similaire mais avec des raisons différentes derrière ...
J'utilise Laravel Valet sur un projet Vanilla PHP avec Laravel Mix . Lorsque j'ai ouvert le site dans Chrome, des erreurs net::ERR_INCOMPLETE_CHUNKED_ENCODING étaient générées. (Si le site était chargé sur le protocole HTTPS, l'erreur était remplacée par net::ERR_SPDY_PROTOCOL_ERROR.)
J'ai vérifié que php.ini et opcache n'étaient pas activés. J'ai constaté 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 qu'une chaîne de requête apparaisse dans l'URL des actifs (curieusement, un seul en particulier?).
J'ai supprimé mix.version() pour l'environnement local et le site se charge parfaitement dans mon Chrome, à la fois sur les protocoles HTTP et HTTPS.
J'ai eu ce problème (montrant ERR_INCOMPLETE_CHUNKED_ENCODING dans Chrome, rien dans les autres navigateurs). Le problème était que mon fournisseur d’hébergement GoDaddy ajoutait un script de surveillance à la fin de ma sortie.
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.
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 le navigateur Chrome.
Fascinant de voir le nombre de causes différentes de ce problème!
Beaucoup disent que c'est un problème de Chrome, alors j'ai essayé Safari et je rencontrais toujours des problèmes. Nous avons ensuite essayé toutes les solutions de ce fil, notamment désactiver ma protection en temps réel AVG, sans succès.
Pour moi, le problème était mon fichier .htaccess. Tout ce qu'il contenait était FallbackResource index.php, mais lorsque je l'ai renommé en htaccess.txt, mon problème a été résolu.
Dans mon cas, il s'agissait de HTML. Il y avait une réponse '\ n' dans json à l'origine du problème. Alors j'ai enlevé ça.
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
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.
Cela se produit généralement lorsque le client envoie une rafale de demandes au serveur, à côté d'un événement côté client.
Ceci est généralement le signe d'une "mauvaise" programmation côté client.
Imaginez que je mette à jour toutes les lignes d'un tableau.
Le problème est d'envoyer une demande pour mettre à jour chaque ligne (beaucoup de demandes en rafale sans attendre que la demande soit terminée). Pour le corriger, assurez-vous que la demande est complète avant d’en envoyer une autre.
Le bon moyen serait d'envoyer une demande avec toutes les lignes mises à jour. (une requête)
Dans un premier temps, regardez donc ce qui se passe côté client et modifiez le code si nécessaire.
Utilisez Wireshark pour identifier ce qui ne va pas dans les demandes.
je suppose que le serveur ne gère pas correctement l'encodage de transfert en bloc. Il doit mettre les fichiers fragmentés avec un bloc terminal pour indiquer que tout le fichier a été transféré. Pour que le code ci-dessous fonctionne
echo "\n";
flush();
ob_flush();
exit(0);
J'obtenais net::ERR_INCOMPLETE_CHUNKED_ENCODING; après une inspection minutieuse de l'erreur de serveur, j'ai constaté que c'était dû au délai d'attente de PHP exécution du script.
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: dépassement du délai d'exécution maximal de 30 secondes