2014-09-02 18 views
17

Sto usando jetty-9.2.2 con CometD-3.0.1. Vedo un avviso di sotto nella mia configurazione. Viene ~ 4,5 volte in un giorno .:Avviso Jetty-9: badMessage: 400 Illegal character

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

Non ci sono dettagli che possono essere il debug dal messaggio di avviso. Ho già registrato una richiesta https://bugs.eclipse.org/bugs/show_bug.cgi?id=443049 per fornire un avviso dettagliato.

Nel frattempo voglio sapere che cosa sta causando questo avviso? Posso ignorare questo o alcuni messaggi sono persi a causa di questo?

risposta

5

Aggiornamento maggio 2017

Per gli utenti Jetty 9.3+, si potrebbe vedere un messaggio di log che rende questo codice di risposta più chiaro.

Vedere Header parse error after upgrade to Jetty 9.3 per dettagli.

risposta originale

Il Bad Message: 400 Illegal Character possono verificarsi durante l'analisi di un cattivo richiesta HTTP.

Questa è la risposta all'errore HTTP rilevata dal client.

Alcune (non tutte) situazioni in cui può verificarsi.

  • L'EOL non è "\ r \ n" (CR + LF) (requisito spec HTTP)
  • Il token metodo HTTP è o non riconosciuto o ha spazi invalida dopo che
  • la versione HTTP è caratteri non validi non riconosciute o ha
  • nome
  • HTTP Header non segue spec
  • valore
  • HTTP Header non segue spec

Questo messaggio è comune a p server pubblici (internet).

Hai richieste HTTP errate in arrivo. Perché?

  • Un client HTTP legittima ha un bug
  • Un client HTTP legittimo non sta seguendo le specifiche HTTP
  • un client non HTTP ha tentato di connettersi al server (come ad esempio il tentativo di utilizzare non criptato HTTP su uno SSL/TLS/HTTPS porto, o anche qualcosa di strano come un client di posta SMTP/IMAP tentativo di parlare con il porta HTTP)
  • un client malevolo sta tentando di sondare il sistema per le debolezze
+0

Grazie ma non ho visto alcun errore nel vecchio jettyv7.6. Questi errori hanno iniziato a venire dopo aver aggiornato il mio server jetty alla 9.2.2. Quindi c'è qualche carattere particolare nella richiesta che è stato permesso in precedenza ma non ora? –

+0

Non ha nulla a che fare con Jetty 7 vs Jetty 9, questo livello di errore/avvertimento HTTP era presente anche nel Jetty 7. –

+0

In effetti, Jetty 9 è più indulgente con l'analisi (questo è il risultato del lavoro con gli RFC HTTP aggiornati, WebSocket e HTTP/2) –

3

Jetty è Cauti informazioni dettagliate sui messaggi di errore che includono i dati inviati dall'utente, in quanto questi possono essere parte di un attacco, anche se l'eco è solo per un terminale.

Tuttavia, possiamo fare meglio e registrare alcuni dati sterilizzati. Agire sul bugzilla

22

Ho avuto lo stesso errore, poi ho scoperto che è stato causato da sto usando https nell'URL anziché http. (La mia applicazione supporta solo http in quel momento. Dopo aver cambiato https su http, è stato risolto.

+2

Grazie !!! E mi fa risparmiare di una lunga notte di debug –

+0

Vorrei che la nostra squadra aveva visto in precedenza ... – PragmaticProgrammer

0

Questo errore può essere causato, come è stato per me, da uno stupido errore.

Durante il test sull'istanza di Jetty localhost, ho ricevuto un messaggio di 400 caratteri illegali molto simile. Poi ho capito perché. Avevo semplicemente assunto indirizzo applicazioni sul mio molo locale era:

https://localhost:8080

mentre l'indirizzo corretto è non garantito:

http://localhost:8080

Nessun problema dopo.

+0

Ops - Mi dispiace - vedo che la mia risposta ha di fatto già stata data in precedenza da S. Du. Forse questa risposta dovrebbe essere cancellata. –