web-dev-qa-db-fra.com

en amont, envoi d'en-tête trop volumineux lors de la lecture de l'en-tête de réponse en amont

Je reçois ce genre d'erreurs:

2014/05/24 11:49:06 [erreur] 8376 # 0: * 54031 En-tête envoyé en-tête trop grand lors de la lecture de l'en-tête de la réponse en amont, client: 107.21.193.210, serveur: aamjanata.com, requête: "GET/the- chroniques de lavage de cerveau parrainées par le gouvernement du Gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles- sponsorisé par gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by- gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles- sponsorisé- par-gujarat-government /,% 20https: /aamjanata.com/the-brainwash-chronicles- sponsorisé-by-gujarat-government/ ,% 20https: /aamjanata.com/the-brainwash-chronicles- sponsorisé- par-gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles- parrainé- par-gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https:/aamjanata.com/t Chroniques de lavage de cerveau parrainées par le gouvernement du Gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government /,% 20https: /aamjanata.com/the-brainwash- chroniques sponsorisées par le gouvernement du Gujarat /,% 20https: /aamjanata.com/the-brainwash-chronicles-parrainées- par-gujarat-gouvernement/,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored- par-gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles-source-parrainé-par-gujarat-gouvernement/,%20https: //aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat -gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles- sponsorisé-par-gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/, % 20https: /aamjanata.com/the-brainwash- chroniques- parrainé- par-gujarat-gouvernement /,% 20https: /aamjanata.com/the-brainwash- chroniques- parrainé- par-gujarat-gouvernement /,% 20https:/aamjanata.com/the-brainwash-chronicles-sponsored-by-gujarat-government/,%20https:/aamjanata.com/the-brainwash-ch ronicles-sponsorisé-par-gujarat-gouvernement /,% 20ht

C'est toujours pareil. Une URL répétée maintes et maintes fois avec une virgule. Je ne peux pas comprendre ce qui cause ça. Quelqu'un a une idée?

Mise à jour: une autre erreur:

http request count is zero while sending response to client

Voici la config. Il y a d'autres choses non pertinentes, mais cette partie a été ajoutée/modifiée

fastcgi_cache_path /var/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$Host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;
    # Upstream to abstract backend connection(s) for PHP.
    upstream php {
            #this should match value of "listen" directive in php-fpm pool
            server unix:/var/run/php5-fpm.sock;
    }

Et ensuite dans le bloc serveur: set $ skip_cache 0;

    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
            set $skip_cache 1;
    }
    if ($query_string != "") {
            set $skip_cache 1;
    }

    # Don't cache uris containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
            set $skip_cache 1;
    }

    # Don't use the cache for logged in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
            set $skip_cache 1;
    }

    location / {
            # This is cool because no php is touched for static content.
            # include the "?$args" part so non-default permalinks doesn't break when using query string
            try_files $uri $uri/ /index.php?$args;
    }


    location ~ \.php$ {
            try_files $uri /index.php;
            include fastcgi_params;
            fastcgi_pass php;
            fastcgi_read_timeout 3000;

            fastcgi_cache_bypass $skip_cache;
            fastcgi_no_cache $skip_cache;

            fastcgi_cache WORDPRESS;
            fastcgi_cache_valid  60m;
    }

    location ~ /purge(/.*) {
        fastcgi_cache_purge WORDPRESS "$scheme$request_method$Host$1";
    }`
201
Vidyut

Ajouter ce qui suit à votre fichier de configuration

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;
348
Neo

Si nginx est exécuté en tant que proxy/proxy inverse

c'est-à-dire pour les utilisateurs de ngx_http_proxy_module

En plus de fastcgi, le module proxy enregistre également l'en-tête de la requête dans un tampon temporaire.

Donc, vous devrez peut-être aussi augmenter le proxy_buffer_size et le proxy_buffers, ou le désactiver complètement (Veuillez lire le documentation de nginx ).

Exemple de configuration de la mise en mémoire tampon du proxy

http {
  proxy_buffer_size   128k;
  proxy_buffers   4 256k;
  proxy_busy_buffers_size   256k;
}

Exemple de désactivation de votre tampon proxy (recommandé pour les serveurs d'interrogation longs)

http {
  proxy_buffering off;
}

Pour plus d'informations: Documentation du module proxy Nginx

113
amd

upstream sent too big header while reading response header from upstream est la manière générique de nginx de dire "je n'aime pas ce que je vois"

  1. Votre thread de serveur en amont s'est écrasé
  2. Le serveur en amont a renvoyé un en-tête non valide.
  3. La notification/les avertissements renvoyés par STDERR ont débordé de leur mémoire tampon et ont été fermés, ainsi que STDOUT.

3: Regardez les journaux des erreurs au-dessus du message. Est-ce que le flux est en cours avec les lignes enregistrées précédant le message? PHP message: PHP Notice: Undefined index: Exemple d'extrait d'une boucle dans mon fichier journal:

2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
... // 20 lines of same
PHP message: PHP Notice:  Undefined index: Firstname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Lastname in /srv/www/classes/data_convert.php on line 1090
PHP message: PHP Notice:  Undef
2015/11/23 10:30:02 [error] 32451#0: *580927 FastCGI sent in stderr: "ta_convert.php on line 1090
PHP message: PHP Notice:  Undefined index: Firstname

vous pouvez voir sur la 3ème ligne à partir du bas que la limite de mémoire tampon a été atteinte, dépassée et que le fil suivant a été écrit dessus. Nginx a ensuite fermé la connexion et renvoyé 502 au client.

2: enregistre tous les en-têtes envoyés par demande, examinez-les et assurez-vous qu'ils sont conformes aux normes (nginx n'autorise pas les fichiers de plus de 24 heures à supprimer/supprimer un cookie, en envoyant une longueur de contenu non valide car les messages d'erreur étaient mis en mémoire tampon avant que le contenu ne soit compté. ..). L'appel à une fonction getallheaders peut généralement aider dans des situations de code abstrait php obtenir tous les en-têtes

les exemples comprennent:

<?php
//expire cookie
setcookie ( 'bookmark', '', strtotime('2012-01-01 00:00:00') );
// nginx will refuse this header response, too far past to accept
....
?>

et ça:

<?php
header('Content-type: image/jpg');
?>

<?php   //a space was injected into the output above this line
header('Content-length: ' . filesize('image.jpg') );
echo file_get_contents('image.jpg');
// error! the response is now 1-byte longer than header!!
?>

1: vérifiez ou créez un journal de script pour vous assurer que votre thread atteint le bon point final et ne quitte pas avant la fin.

21
ppostma1

Instructions de Plesk

Dans Plesk 12, nginx fonctionnait comme un proxy inverse (ce qui, à mon avis, est le comportement par défaut). Donc, la réponse actuelle ne fonctionne pas car nginx est également exécuté en tant que proxy.

Je suis allé à Subscriptions | [subscription domain] | Websites & Domains (tab) | [Virtual Host domain] | Web Server Settings.

Ensuite, au bas de cette page, vous pouvez définir le Directives nginx supplémentaires que je définis comme étant une combinaison des deux premières réponses ici:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;
10
icc97

Si vous utilisez le framework Symfony: Avant de vous lancer dans la configuration de Nginx, essayez de désactiver ChromePHP.

1 - Ouvrez app/config/config_dev.yml

2 - Commentez ces lignes:

#chromephp:
    #type:   chromephp
    #level:  info

ChromePHP contient les informations de débogage codées JSON dans l'en-tête X-ChromePhp-Data, qui est trop volumineux pour la configuration par défaut de nginx avec fastcgi.

Source: https://github.com/symfony/symfony/issues/8413#issuecomment-20412848

5
Lucas Bustamante

Nous avons fini par nous rendre compte que notre seul serveur qui rencontrait ce problème avait bloqué la configuration de fpm, ce qui entraînait des erreurs/avertissements/notifications php qui seraient normalement consignés sur le disque et envoyés via le socket FCGI. Il semble y avoir un bogue d’analyse lorsqu’une partie de l’en-tête est divisée en plusieurs morceaux de mémoire tampon.

Donc, définir php_admin_value[error_log] sur quelque chose de réellement inscriptible et redémarrer php-fpm était suffisant pour résoudre le problème.

Nous pourrions reproduire le problème avec un script plus petit:

<?php
for ($i = 0; $i<$_GET['iterations']; $i++)
    error_log(str_pad("a", $_GET['size'], "a"));
echo "got here\n";

Augmenter les tampons rendait les 502 plus difficiles à atteindre mais pas impossibles, par exemple en natif:

bash-4.1# for it in {30..200..3}; do for size in {100..250..3}; do echo "size=$size iterations=$it $(curl -sv "http://localhost/debug.php?size=$size&iterations=$it" 2>&1 | egrep '^< HTTP')"; done; done | grep 502 | head
size=121 iterations=30 < HTTP/1.1 502 Bad Gateway
size=109 iterations=33 < HTTP/1.1 502 Bad Gateway
size=232 iterations=33 < HTTP/1.1 502 Bad Gateway
size=241 iterations=48 < HTTP/1.1 502 Bad Gateway
size=145 iterations=51 < HTTP/1.1 502 Bad Gateway
size=226 iterations=51 < HTTP/1.1 502 Bad Gateway
size=190 iterations=60 < HTTP/1.1 502 Bad Gateway
size=115 iterations=63 < HTTP/1.1 502 Bad Gateway
size=109 iterations=66 < HTTP/1.1 502 Bad Gateway
size=163 iterations=69 < HTTP/1.1 502 Bad Gateway
[... there would be more here, but I piped through head ...]

fastcgi_buffers 16 16k; fastcgi_buffer_size 32k;:

bash-4.1# for it in {30..200..3}; do for size in {100..250..3}; do echo "size=$size iterations=$it $(curl -sv "http://localhost/debug.php?size=$size&iterations=$it" 2>&1 | egrep '^< HTTP')"; done; done | grep 502 | head
size=223 iterations=69 < HTTP/1.1 502 Bad Gateway
size=184 iterations=165 < HTTP/1.1 502 Bad Gateway
size=151 iterations=198 < HTTP/1.1 502 Bad Gateway

Donc, je pense que la bonne réponse est: corrigez votre configuration fpm pour qu’elle enregistre les erreurs sur le disque.

2
lyte