Ответ 1
У меня была такая же ошибка, а потом выяснилось, что это вызвано тем, что я использую https в URL вместо http. (Мое приложение поддерживает только http в то время.) После изменения https на http он был решен.
Я использую jetty-9.2.2 с CometD-3.0.1. В моей настройке я вижу предупреждение ниже. Он достигает ~ 4,5 раза в день:
2014-08-28 08:50:53.712:WARN:oejh.HttpParser:qtp607635164-15194: badMessage:
400 Illegal character for [email protected]{r=1,a=IDLE,uri=-}
Нет никаких подробностей, которые можно отладить из предупреждающего сообщения. Я уже зарегистрировал запрос https://bugs.eclipse.org/bugs/show_bug.cgi?id=443049, чтобы предоставить подробное предупреждение.
Между тем я хочу знать, что вызывает это предупреждение? Могу ли я игнорировать это или некоторые сообщения теряются из-за этого?
У меня была такая же ошибка, а потом выяснилось, что это вызвано тем, что я использую https в URL вместо http. (Мое приложение поддерживает только http в то время.) После изменения https на http он был решен.
Обновление до 2017 года
Для пользователей Jetty 9.3+ вы можете увидеть сообщение журнала, которое делает этот код ответа более понятным.
Подробнее см. Ошибка анализа заголовка после обновления до Jetty 9.3.
Оригинальный ответ
Bad Message: 400 Illegal Character
может возникать при анализе плохого HTTP-запроса.
Это ответ HTTP-ошибки, который видит клиент.
Некоторые (не все) ситуации, в которых это может произойти.
Это сообщение распространено на общедоступных серверах.
У вас возникли неудачные HTTP-запросы. Почему?
Эта ошибка может быть вызвана, как и для меня, глупой маленькой ошибкой.
При тестировании на моем экземпляре Jethost localhost я получил очень похожее сообщение 400 Illegal Character. Тогда я понял, почему. Я просто предположил, что адрес приложения на моем местном причале был:
https://localhost:8080
тогда как правильный адрес не был защищен:
http://localhost:8080
Никаких проблем после этого.
Jetty осторожно относится к подробным сообщениям об ошибках, которые включают данные, отправленные пользователем, так как они могут быть частью атаки - даже если echo'd просто для терминала.
Однако мы можем сделать лучше и занести в журнал некоторые дезинфицированные данные. Действуя на bugzilla
Ну, я столкнулся с этой проблемой, потому что я принял "http://" как "https://"