9.0.16.0 - this is the version installed with apt-get tomcat9 on ubuntu 18.04
Thank you for your feedback. John On 8/1/19, Konstantin Kolinko <knst.koli...@gmail.com> wrote: > чт, 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 > org.apache.catalina.connector.RECYCLE_FACADES=true > 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 > leak. > > 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. > > https://tomcat.apache.org/security-9.html > > 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], > > org.apache.juli.logging.UserDataHelper.CONFIG > org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME > > [1] > https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Properties > > [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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
