web-dev-qa-db-fra.com

Comment réparer nginx jette 400 en-têtes de requête incorrecte sur n'importe quel outil de test d'en-tête?

Mon site utilise nginx et le site de test avec des outils de test d'en-tête, par exemple. http://www.webconfs.com/http-header-check.php mais à chaque fois, il est indiqué que 400 requêtes incorrectes sont listées ci-dessous. Bien que toutes mes pages se chargent parfaitement dans le navigateur et quand je vois dans la console chrome, il indique le code d'état 200OK.

HTTP/1.1 400 Bad Request => 
Server => nginx
Date => Fri, 07 Sep 2012 09:40:09 GMT
Content-Type => text/html
Content-Length => 166
Connection => close

Je ne comprends vraiment pas quel est le problème avec la configuration de mon serveur?

Un peu de googler suggère d'augmenter la taille de la mémoire tampon en utilisant, et je l'ai augmenté à la suivante:

large_client_header_buffers 4 16k;

Les mêmes résultats persistent. 

Quelqu'un peut-il me guider dans la bonne direction?

nginx
21
ʞɹᴉʞ ǝʌɐp

Comme l'a déclaré Maxim Dounin dans les commentaires ci-dessus :

Lorsque nginx renvoie 400 (demande incorrecte), il enregistre le motif en erreur log, au niveau "info". D'où un moyen évident de savoir ce qui se passe est de configurer error_log enregistrer les messages au niveau "info" et consulter le journal des erreurs lorsque essai.

53
Emmanuel Joubaud

Oui, changer le niveau de débogage error_to comme Emmanuel Joubaud le suggérait (modifier/etc/nginx/sites-enabled/default)

        error_log /var/log/nginx/error.log debug;

Puis, après avoir restauré nginx, je suis entré dans le journal des erreurs avec mon application Python sous uwsgi:

        2017/02/08 22:32:24 [debug] 1322#1322: *1 connect to unix:///run/uwsgi/app/socket, fd:20 #2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 connected
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream connect: 0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 posix_memalign: 0000560E1F25A2A0:128 @16
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request body
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer buf fl:0 s:454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer in: 0000560E1F2A0928
        2017/02/08 22:32:24 [debug] 1322#1322: *1 writev: 454 of 454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer out: 0000000000000000
        2017/02/08 22:32:24 [debug] 1322#1322: *1 event timer add: 20: 60000:1486593204249
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http finalize request: -4, "/?" a:1, c:2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http request count:2 blk:0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5E40
        2017/02/08 22:32:24 [debug] 1322#1322: *1 delete posted event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http run request: "/?"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream check client, write event:1, "/"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream recv(): -1 (11: Resource temporarily unavailable)

Ensuite, j’ai jeté un coup d’œil à mon journal d’Uwsgi et découvert que:

        Invalid HTTP_Host header: 'www.mysite.local'. You may need to add u'www.mysite.local' to ALLOWED_HOSTS.
        [pid: 10903|app: 0|req: 2/4] 192.168.221.2 () {38 vars in 450 bytes} [Wed Feb  8 22:32:24 2017] GET / => generated 54098 bytes in 55 msecs (HTTP/1.1 400) 4 headers in 135 bytes (1 switches on core 0)

Et l’ajout de www.mysite.local au fichier settings.py ALLOWED_CONFIGS a corrigé le problème :)

        ALLOWED_HOSTS = ['www.mysite.local']
6
PHZ.fi-Pharazon

Une cause peut être un codage non valide dans la demande d'URL. Tels que% passés non codés.

6
Martlark

Juste pour clarifier, dans /etc/nginx/nginx.conf , vous pouvez mettre la ligne au début du fichier

error_log /var/log/nginx/error.log debug;

Et puis redémarrez nginx:

Sudo service nginx restart

De cette façon, vous pouvez détailler ce que fait nginx et pourquoi il renvoie le code d’état 400.

4
Camilo

normalement, la méthode de Maxim Donnie peut trouver la raison. Mais j'ai rencontré une mauvaise requête 400 ne sera pas connecté à err_log. J'ai trouvé la raison de l'aide avec tcpdump

0
Dan