it-swarm.com.de

Wie kann man beheben, dass Nginx 400 fehlerhafte Anforderungsheader in beliebigen Header-Testwerkzeugen löst?

Ich habe meine Site, die Nginx verwendet, und Testing Site mit Header-Testwerkzeugen, z. http://www.webconfs.com/http-header-check.php aber jedes Mal, wenn 400 400 schlechte Anfrage angezeigt wird, ist der Ausgang des Tools. Obwohl alle meine Seiten im Browser einwandfrei geladen werden, und wenn ich in Chrome Console sehe, wird der Statuscode 200OK angezeigt.

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

Ich verstehe wirklich nicht, was das Problem mit meiner Server-Konfiguration ist?

Ein bisschen googeln schlägt vor, die Puffergröße mit zu erhöhen, und ich habe es auf Folgendes erhöht:

large_client_header_buffers 4 16k;

Die gleichen Ergebnisse bleiben bestehen. 

Kann mich jemand in die richtige Richtung führen?

21

Wie von Maxim Dounin in den obigen Kommentaren angegeben:

Wenn nginx 400 (Bad Request) zurückgibt, wird der Grund in Fehler .__ protokolliert. Protokoll, auf "Info" -Ebene. Eine naheliegende Möglichkeit, um herauszufinden, was los ist ist zu konfigurieren Fehlerprotokoll um Meldungen auf "Info" -Ebene zu protokollieren und das Fehlerprotokoll einzusehen, wenn testen.

53

Ja, wenn Sie den error_to-Debug-Level ändern, wie von Emmanuel Joubaud vorgeschlagen, klappt (edit/etc/nginx/sites-enabled/default):

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

Nach dem Restaring von Nginx kam ich mit meiner Python-Anwendung in das Fehlerprotokoll und verwendete 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)

Dann schaute ich in mein uwsgi-Protokoll und fand das heraus:

        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)

Durch Hinzufügen von www.mysite.local zu den Einstellungen.py ALLOWED_CONFIGS wurde das Problem mit .__ behoben. :)

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

Ursache kann eine ungültige Kodierung in der URL-Anforderung sein. Wie% wird unverschlüsselt übergeben.

6
Martlark

Um dies zu verdeutlichen, können Sie in /etc/nginx/nginx.conf die Zeile am Anfang der Datei einfügen

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

Und dann nginx neu starten:

Sudo service nginx restart

Auf diese Weise können Sie detailliert beschreiben, was Nginx macht und warum es den Statuscode 400 zurückgibt.

4
Camilo

normalerweise kann Maxim Donnies Methode den Grund finden. Ich habe jedoch festgestellt, dass eine fehlerhafte 400-Anforderung nicht in err_log protokolliert wird. Ich habe den Grund mit der Hilfe bei tcpdump gefunden

0
Dan