чт, 1 авг. 2019 г. в 22:11, John Dale <jcdw...@gmail.com>:
> Great feedback.  Thanks.
> I am the network department. :)
> This is a public facing service and shortly after I see this in the
> log, I get an OOM exception and server shutdown.  Twice now this
> morning.

The exception text is a bit misleading. It says "header", but it
actually caused by sanity checks that are done when parsing the first
line of the request (it precedes all the headers) aka the "request
line". Thus you can see "parseRequestLine()" in the stack trace.

As you may know, starting with HTTP/1.1 a client can send several HTTP
request over the same connection (aka "keep alive", also "request
pipelining"). If the length of the preceding request was not processed
correctly either because the client sent an incorrect value of
Content-Length header or if there is a bug, Tomcat will start parsing
a new request at a wrong place and you will see such an error.

Other cause of similar errors is when a client tries to connect using
https: protocol to a http: connector. A small difference is that in
that case the sanity check will be triggered earlier: when parsing the
HTTP method name (the first component of the request line). In your
case the error message says about the HTTP protocol version (the third
component of the request line).

1. Personally, I always run with
as documented in [1].

This property helps if there is a bug in a web application.

2. Make sure that you use an up-to-date version of Tomcat. You didn't
tell us what version of Tomcat 9.0.x you are using.

3. If there is bug that causes Tomcat to incorrectly process a length
of a request (a known way to trigger such a bug), I think that it will
be treated as a security vulnerability that leads to an information

See CVE-2018-8037 )fixed in 9.0.10), CVE-2017-5651 and CVE-2017-5647
(both fixed in 9.0.0.M19) for an idea.


Maybe you can configure creation of a heap dump during the OOM, so
that it could be diagnosed what is causing a memory leak?

Note that there is a procedure to report security issues [2]. A public
Bugzilla should not be used for such reports.

4. The error message that you saw is printed only once in every 24
hours. The latter occurrences during the same day are suppressed
(logged at DEBUG level) to prevent flooding one's log files. This
behaviour is controlled by system properties [3],



[2] https://tomcat.apache.org/security.html

[3] https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Logging

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to