L'en-tête envoyé en amont est trop volumineux lors de la lecture de l'en-tête de réponse en amont - erreur NGINX

Alors que je travaillais sur mon site Web client basé sur WooCommerce, il m'est arrivé de voir la page de paiement échouer avec un message d'erreur "502 Bad gateway". Je soupçonnais que le problème pouvait être dû à NGINX et c'était vrai. Le journal des erreurs NGINX indique que "l'en-tête envoyé en amont est trop volumineux lors de la lecture de l'en-tête de réponse de la requête en amont :GET /checkout/ HTTP/1.1, en amont :fastcgi://unix:/var/run/php-fpm/php- fpm.sock ‘. Dans ce didacticiel, je vais vous expliquer en quoi consiste l'erreur et comment la corriger.

Qu'est-ce que l'erreur "Upstream a envoyé un en-tête trop gros lors de la lecture en-tête de réponse de l'amont" ?

Je comprends que la page semble envoyer un en-tête trop gros par rapport à la capacité du destinataire. Mais quelle était la taille de l'en-tête qui était trop grande pour que le serveur puisse la gérer ? Comme la page que j'ai eue, l'erreur était la page de paiement, qui comprenait 10 articles ajoutés au panier. Par conséquent, les cookies, le contenu de la page étaient tous élevés et cela aurait pu entraîner une taille d'en-tête plus grande. Alors, comment trouver ce que les en-têtes de réponse incluent ? C'est simple.

1. Lancez le navigateur Chrome, faites un clic droit et sélectionnez Inspect
2. Cliquez sur Network onglet
3. Recharger la page
4. Sélectionnez l'une des requêtes HTTP dans le panneau de gauche et affichez les en-têtes HTTP dans le panneau de droite.

C'est bien, vous savez pour afficher les en-têtes HTTP. Mais pourquoi le serveur a-t-il échoué avec une erreur "L'en-tête envoyé en amont est trop gros lors de la lecture de l'en-tête de réponse en amont" ? Eh bien, la réponse est que chaque serveur Web a une taille d'en-tête maximale définie et que les en-têtes de requête HTTP envoyés étaient trop volumineux que celui défini dans le serveur Web. Vous trouverez ci-dessous la limite maximale de taille d'en-tête sur divers serveurs Web.

• Serveur Web Apache – 8K
• NGINX – 4K à 8K
• IIS (varie selon chaque version) – 8K à 16K
• Tomcat (varie selon chaque version) :8K à 48K.

Comme le serveur Web que j'utilise est NGINX, la limite de taille d'en-tête par défaut est de 4K à 8K. Par défaut, NGINX utilise la taille de page système, qui est de 4K dans la plupart des systèmes. Vous pouvez le trouver en utilisant la commande ci-dessous :

# getconf PAGESIZE
4096

Voici un extrait qui explique les tailles de tampon de réponse NGINX FastCGI.

Par défaut, lorsque Nginx commence à recevoir une réponse d'un backend FastCGI (tel que PHP-FPM), il met la réponse en mémoire tampon avant de la transmettre au client. Toute réponse supérieure à la taille de tampon définie est enregistrée dans un fichier temporaire sur le disque.

Les deux paramètres liés à la mise en mémoire tampon des réponses FastCGI sont :

fastcgi_buffers 
fastcgi_buffer_size

fastcgi_buffers – contrôle le nombre et la taille de la mémoire des segments de tampon utilisés pour la charge utile de la réponse FastCGI.

fastcgi_buffer_size – contrôle la taille de la mémoire tampon utilisée pour contenir le premier bloc de réponse fastCGI à partir des en-têtes de réponse HTTP.

Selon la documentation NGNIX, vous n'avez pas besoin d'ajuster la valeur par défaut des paramètres de réponse fastCGI, car le NGINX utilise par défaut la plus petite taille de page de 4 Ko et il devrait correspondre à la plupart des demandes d'en-tête HTTP. Cependant, cela ne semble pas convenir à mon cas. La même documentation indique que certains des frameworks peuvent pousser une grande quantité de données de cookies via Set-Cookie l'en-tête HTTP et cela pourrait faire exploser le tampon, entraînant une erreur HTTP 500. Dans de tels cas, vous devrez peut-être augmenter la taille de la mémoire tampon à 8 k/16 k/32 k pour prendre en charge un en-tête HTTP en amont plus volumineux.

Comment trouver les tailles moyennes et maximales des réponses FastCGI reçues par le Web serveur ?

Cela peut être découvert en grippant les fichiers journaux d'accès NGINX. Pour ce faire, exécutez la commande ci-dessous en fournissant le access_log fichier en entrée

$ awk '($9 ~ /200/) { i++;sum+=$10;max=$10>max?$10:max; } END { printf("Maximum: %d\nAverage: %d\n",max,i?sum/i:0); }' access.log

Exemple sur mon serveur Web :

Maximum: 3501304
Average: 21065

Remarque  :seule la réponse HTTP 200 OK a été prise en compte.

D'après l'instantané ci-dessus, il est clair que la taille moyenne de la mémoire tampon est supérieure à 21 Ko. Nous devons donc définir une taille de tampon légèrement supérieure à la demande moyenne, qui peut probablement être de 32 Ko. Pour ce faire, ouvrez le fichier nginx.conf ajoutez les lignes ci-dessous sous location section – location ~ \.php$ { }

fastcgi_buffers 32 32k;
fastcgi_buffer_size 32k;

Remarque :Vous devrez peut-être définir une valeur de tampon inférieure. J'avais défini 32 Ko car la taille moyenne était supérieure à 21 Ko.

En savoir plus sur les tampons de réponse FastCGI ici.