2014-09-02 31 views
17

Ich benutze Jetty-9.2.2 mit CometD-3.0.1. Ich sehe unten Warnung in meinem Setup. Es kommt ~ 4,5 Mal an einem Tag .:Jetty-9 Warnung: badMessage: 400 Unzulässiges Zeichen

2014-08-28 08:50:53.712:WARN:oejh.HttpParser:qtp607635164-15194: badMessage: 
    400 Illegal character for [email protected]{r=1,a=IDLE,uri=-} 

Es gibt keine Details, die von der Warnmeldung debuggt werden können. Ich habe bereits eine Anfrage https://bugs.eclipse.org/bugs/show_bug.cgi?id=443049 geloggt, um eine detaillierte Warnung zu geben.

In der Zwischenzeit möchte ich wissen, was diese Warnung verursacht? Kann ich das ignorieren oder einige Nachrichten sind deswegen verloren?

Antwort

5

-Update Mai 2017

Für Jetty 9.3+ Benutzer, können Sie eine Log-Meldung, dass dieser Antwortcode mehr deutlich macht.

Weitere Informationen finden Sie unter Header parse error after upgrade to Jetty 9.3.

Original-Antwort

Die Bad Message: 400 Illegal Character während der Analyse eines schlechten HTTP Request auftreten können.

Das ist die HTTP-Fehlerantwort, die der Client sieht.

Einige (nicht alle) Situationen, in denen es auftreten kann.

  • Die EOL nicht "\ r \ n" (CR + LF) (HTTP spec Anforderung)
  • die HTTP-Methode Token wird entweder nicht erkannt oder ungültige Leerzeichen hat, nachdem es
  • die HTTP-Version ist, nicht erkannt oder hat, ist diese Nachricht ungültige Zeichen
  • HTTP-Header-Namen folgen
  • HTTP-Header-Wert folgt nicht spec spec nicht

gemeinsam auf p ublic (Internet) Server.

Sie haben schlechte HTTP-Anfragen. Warum?

  • Ein berechtigtes HTTP-Client hat einen Fehler
  • Ein legitimes HTTP-Client wird im Anschluss an der HTTP-Spezifikation nicht
  • Ein nicht HTTP-Client auf dem Server (wie der Versuch zu verbinden versuchte, auf unverschlüsselte HTTP zu verwenden, ein SSL/TLS/HTTPS-Port, ungerade oder gerade als SMTP/IMAP E-Mail-Client so etwas versuchen, HTTP-Port)
  • ein bösartiger Client versucht zu sondieren Sie das System auf Schwächen
+0

Danke aber ich sah keinen Fehler in alten jettyv7.6. Diese Fehler begannen nach dem Update meines Jetty Servers auf 9.2.2. Gibt es also ein bestimmtes Zeichen in der Anfrage, die vorher erlaubt wurde, aber nicht jetzt? –

+0

Es hat nichts mit Jetty 7 vs Jetty 9 zu tun, diese Ebene von HTTP-Fehler/Warnung war auch in Jetty 7 vorhanden. –

+0

Tatsächlich ist Jetty 9 beim Parsen milder (das ist das Ergebnis der Arbeit mit den aktualisierten HTTP RFCs, WebSocket und HTTP/2) –

3

Jetty ist zu sprechen Vorsicht Dazu gehören detaillierte Fehlermeldungen, die vom Benutzer gesendete Daten enthalten, da diese Teil eines Angriffs sein können - selbst wenn sie nur an ein Terminal gesendet werden.

Wir können jedoch besser und einige bereinigte Daten protokollieren. Handeln auf dem Bugzilla

22

Ich hatte den gleichen Fehler, dann stellte sich heraus, dass es durch die Verwendung von https in der URL anstelle von http verursacht wurde. (Meine Anwendung unterstützt zu diesem Zeitpunkt nur http.) Nachdem https zu http geändert wurde, wurde es gelöst.

+2

Vielen Dank !!! Es rettet mich von einer langen Nacht des Debuggens –

+0

Wünschte, dass unser Team das früher gesehen hatte ... – PragmaticProgrammer

0

Dieser Fehler kann, wie für mich, durch einen albernen kleinen Fehler verursacht werden.

Beim Testen auf meiner localhost Jetty-Instanz erhielt ich eine sehr ähnliche Nachricht 400 Unzulässiger Zeichen. Dann wurde mir klar warum. Ich hatte einfach Anwendungsadreßplatzpuffer auf meinem lokalen Jetty angenommen war:

https://localhost:8080

während die richtige Adresse ungesichert war:

http://localhost:8080

Keine Probleme danach.

+0

Hoppla - Es tut mir leid - ich sehe, dass meine Antwort effektiv bereits oben von S. Du gegeben wurde. Diese Antwort von mir sollte vielleicht gelöscht werden. –

Verwandte Themen