
kennt jemand offizielle oder inoffizielle Dokumente darüber, warum Apache einen Statuscode 400 zurückgibt? Mir ist bewusst, dass dies auf eine fehlerhafte Client-Anforderung zurückzuführen ist, aber was macht eine fehlerhafte Client-Anforderung aus? Ich weiß, dass Dinge wie eine große Anforderungsgröße und ungültige Zeichen einen 400-Statuscode verursachen können, aber ich hätte gerne eine Art definitive Liste.
Beispielsweise werden diese Einzelheiten im „Definitive Guide on Apache“ von O'Reilly nicht erläutert.
Danke! Damien
Antwort1
Soweit ich weiß und fast per Definition: Es kann keine definitive Liste der Ursachen einer 400
Antwort geben, da dieser Antwortcode für alles gilt, was an Apache httpd gesendet wird und nicht als gültige Anfrage analysiert werden kann.
Das ist vielleicht etwas, das"erscheint"einer gültigen Anfrage ähneln oder völliger Unsinn sein.
Die 400
Antwort entspricht WTF*#K
!
Wie von @NikitaKipriyanov kommentiert, zeichnet das Apache-(Fehler-)Protokoll normalerweise auf, welche Anforderungszeile die 400-Antwort ausgelöst hat.
Historisch gesehen wird eine HTTP-Anforderungszeile mit einemWagenrücklauf und Zeilenvorschubund daher zeigt Ihr Protokoll normalerweise alles an, was an Apache gesendet wurde, bis der erste Wagenrücklauf und ein Zeilenvorschub empfangen wurden.
Eine schnelle Suche nach 400 Antworten in meinen Apache-Protokollen zeigt eine Anzahl wiederkehrender Typen „ungültiger Anfragen“:
Die häufigste: einegültig aussehenHTTP 1.1eine Anforderungszeile, bestehend aus demGroß-/Kleinschreibung beachtende Anfragemethode, ARaum, die angeforderteURL, ein andererRaumund dasProtokollversionwie zum Beispiel:
"GET / HTTP/1.1"
Dies wurde höchstwahrscheinlich abgelehnt, weil derHost:
Header nicht in der Anforderung enthalten war und dieser Header in HTTP/1.1 obligatorisch istZiemlich häufig:Binärdaten (Handshake)das erscheint als maskiertes Hex wie zum Beispiel
"\x16\x03\x01\x01\xfc\x01"
Dies wird in diesem Beispiel durch den Versuch verursacht, eine TLS 1.2-Verbindung über den einfachen HTTP-Port 80 (oder einen beliebigen anderen Port, sogar 443, wenn dort kein TLS konfiguriert ist) herzustellen."\x16\x03\x01
ist ein ähnlicher TLS 1 / 1.1 Handshake\x16\x03"
ist ein ähnlicher SSL3-Handshake- in vielen weiteren Variationen
- oder auch nur ein
"\n"
Verbindungsversuche mit einemvöllig anderes Protokollals HTTP(S) an die Webserver-Ports, d. h.
"SSH-2.0-OpenSSH_7.4"
Prüfen, ob SSH auf einem Webserver-Port angeboten wird (ein Trick, der häufig von Systemadministratoren und Benutzern verwendet wird, um eine Unternehmens-Firewall zu umgehen)"SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1"
Suche nach einem VPN-Endpunkt, der denSSTP-Protokoll- und andere.