19

I am running SpringBoot Application just checked server logs and got several errors like this. I can't understand what can cause it as the error appears everyday after 12/24 hours.

Tomcat Version running on 8.5.11

2018-03-04 17:03:26 [http-nio-8080-exec-85] INFO  o.a.coyote.http11.Http11Processor - Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
    at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:421)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)
Mikheil Janiashvili
  • 497
  • 1
  • 6
  • 18
  • There's no way to tell from the information provided - you need to capture the request that's causing it and the actual header value in the time of the error. – hovanessyan Mar 14 '18 at 09:26
  • 3
    This error is could occur if you're trying to access unsecured page through https. – abdul Mar 14 '18 at 09:36
  • @hovanessyan yeah that's the reason posting it here, it appears only on production and i don't think its caused from someones call as it happens with same interval. – Mikheil Janiashvili Mar 14 '18 at 09:38
  • 1
    @MishoJaniashvili - posting logs from production without context will not lead to anything more then guessing what might cause the error - "parsing errors will be logged at DEBUG level" - I suggest turn DEBUG on in production for the next 24 hours – hovanessyan Mar 14 '18 at 09:42

3 Answers3

17

This may happen because of parsing HTTPS headers instead of HTTP. Try:

  1. Adding:
    logging.level.org.springframework.web: trace
    logging.level.org.apache: trace
    to your application.properties and see what does Spring says to you.
  2. Check if there are any scheduled activity at that time which refers to other resource encrypted by SSL. See also: java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
coffman21
  • 943
  • 11
  • 18
8

As I have answered in this similar question, check if you are not accidentally requesting with HTTPS protocol instead of HTTP protocol. If you don't configure SSL on Tomcat and you send HTTPS request, it will result to this weird message..

Gondy
  • 4,925
  • 4
  • 40
  • 46
3

I had this error in a Spring Boot 2 (2.0.1.RELEASE) application that was configured to serve HTTPS on port 8443 and redirect port 8080 HTTP traffic to port 8443.

On Microsoft Edge, the application worked as expected, with http://localhost:8080 redirecting to https://localhost:8443. On Chrome 66 however, this would only work once, and then Chrome would complain that "localhost sent an invalid response" (ERR_SSL_PROTOCOL_ERROR).

The server log said: DEBUG 11440 --- [nio-8080-exec-1] o.a.coyote.http11.Http11InputBuffer: Received [ <<unprintable characters>> ] INFO 11440 --- [nio-8080-exec-1] o.apache.coyote.http11.Http11Processor: Error parsing HTTP request header

It turns out that Chrome was adding localhost to its HSTS list because Spring Boot sent back a Strict-Transport-Security: max-age=31536000 ; includeSubDomains header back for https://localhost:8443. So essentially, this issue happened because the client (i.e., browser) was trying to speak HTTPS to an HTTP endpoint.

Adding a .headers().httpStrictTransportSecurity().disable(); in <? extends WebSecurityConfigurerAdapter>.configure fixed the issue, as noted in this StackOverflow question.

sigint
  • 1,842
  • 1
  • 22
  • 27
  • This isn't the solution to the error I came here trying to solve, but it is the solution to another error I was having. We run all our apps of 8080 and 8443 for secure. Lately users have been complaining they can't connect. Their browsers automatically forward to https on :8080, the non secure connector port. Its because we've been converting to spring boot I guess. – Mark D Apr 29 '20 at 21:45