Jetty-9 warning: badMessage: 400 Illegal character

Question

I am using jetty-9.2.2 with CometD-3.0.1. I am seeing below warning in my setup. It comes ~4,5 times in a day.:

2014-08-28 08:50:53.712:WARN:oejh.HttpParser:qtp607635164-15194: badMessage: 
    400 Illegal character for HttpChannelOverHttp@5946f125{r=1,a=IDLE,uri=-}  

There is no details that can be debugged from the warning message. I have already logged a request https://bugs.eclipse.org/bugs/show_bug.cgi?id=443049 to provide detailed warning.

Meanwhile I want to know what is causing this warning? Can I ignore this or some messages are lost because of this?

Solution 1

Change https to http in the url.

I had the same error, then found out it's because my application did not support https, so jetty cannot recognize the https encrypted request.

Solution 2

Update May 2017

For Jetty 9.3+ users, you might see a log message that makes this response code more clear.

See Header parse error after upgrade to Jetty 9.3 for details.

Original Answer

The Bad Message: 400 Illegal Character can occur during parsing of a bad HTTP Request.

That is the HTTP error response that the client sees.

Some (not all) situations in which it can occur.

• The EOL is not "\r\n" (CR + LF) (HTTP spec requirement)
• The HTTP Method token is either not recognized or has invalid whitespace after it
• The HTTP Version is not recognized or has invalid characters
• HTTP Header name does not follow spec
• HTTP Header value does not follow spec

This message is common on public (internet facing) servers.

You have bad HTTP requests coming in. Why?

• A legitimate HTTP client has a bug
• A legitimate HTTP client is not following the HTTP spec
• A non HTTP client attempted to connect to your server (such as attempting to use non-encrypted HTTP on a SSL/TLS/HTTPS port, or even something as odd as an SMTP/IMAP email client attempting to talk to your HTTP port)
• A malicious client is attempting to probe your system for weaknesses

Solution 3

This error can be caused, as it was for me, by a silly little mistake.

When testing on my localhost Jetty instance, I received a very similar 400 Illegal Character message. Then I realized why. I had simply assumed application address on my local Jetty was:

https://localhost:8080

whereas the correct address was unsecured:

http://localhost:8080

No problems after that.

Solution 4

Jetty is cautious about detailed error messages that include user sent data, as these can be part of an attack - even if echo'd just to a terminal.

However, we can do better and log some sanitised data. Acting on the bugzilla

View more solutions

Comments

[Anuj Khandelwal]

Thanks but I was not seeing any error in old jettyv7.6. These errors started coming after updating my jetty server to 9.2.2. So is there any particular character in the request which was allowed previously but not now ?

[Joakim Erdfelt]

It has nothing to do with Jetty 7 vs Jetty 9, this level of HTTP error/warning was present in Jetty 7 as well.

[Joakim Erdfelt]

In fact, Jetty 9 is more lenient with parsing (this is as a result of the work with the updated HTTP RFCs, WebSocket, and HTTP/2)

[Anuj Khandelwal]

Can I ignore this warning ? In my use case I am deploying cometd in jetty. As discussed with CometD vendors, they are saying to ignore this warning. : groups.google.com/forum/#!topic/cometd-users/V5Dn9np1zz0

[oligofren]

Thanks for the comment on newlines (CRLF). Using unix2dos on the files on Windows fixed the issue :)

[Ben Weaver]

Oops--I am sorry--I see that my answer has effectively already been given above by S. Du. This answer of mine perhaps should be deleted.

[Meg]

I spent more than 12 hours trying to figure out what the issue was. This works. Thank you!