Hi Chris, Thanks for trying to help here. As suggested I have checked the access logs and find the below error line when ever the above exception occurs in catalina.out.
"GET null null" 400 - Thanks Ram On Wed, Dec 4, 2019 at 7:41 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Ram, > > On 12/4/19 06:02, thulasiram k wrote: > > Hi, > > > > we recently upgrade our tomcat from 7.0.91 to 7.0.94 in windows > > platform. Post upgrade we are seeing the below exception in logs > > very frequently. can you please suggest to avoid this. > > > > Dec 02, 2019 1:34:09 PM > > org.apache.coyote.http11.AbstractHttp11Processor process INFO: > > 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 the > > request target. The valid characters are defined in RFC 7230 and > > RFC 3986 at > > org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(Internal > InputBuffer.java:199) > > > > > at > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1 > 1Processor.java:1050) > > > > > at > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A > bstractProtocol.java:637) > > > > > at > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint > .java:319) > > > > > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool > Executor.java:1128) > > > > > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo > lExecutor.java:628) > > > > > at > > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr > ead.java:61) > > > > > at java.base/java.lang.Thread.run(Thread.java:830) > > > > And will this effect anything? as I didn't receive any complaints > > from users. > > No spec-compliant client should be sending anything in an HTTP header > that causes a problem. Unfortunately, not all clients (browsers) are > actually spec-compliant, and it's very easy to write an application > that also violates the spec. > > Each version of Tomcat becomes more and more strict in order to either > improve security or improve the web ecosystem in general or both. > > When you get this error, do you see an entry in your access log? Can > you correlate the error with what you see in the access log? You > should see a 400 status code for this request. If you aren't sure > which character is illegal, post the whole line from the request > (perhaps sanitized for hostname, IP address, any secrets it may -- but > shouldn't -- contain) and we'll take a look. > > A few years ago, Tomcat changed the way it performs Cookie parsing to > be much more strict and that broke a bunch of applications, including > my own. It turned out that we were writing a cookie value that was > actually not allowed, but Tomcat was allowing it. Upgrading would have > caused my application to break in two places: when writing that Cookie > value and also when reading it. The solution was to fix the > application to encode those cookie values so that they were HTTP-safe. > (In our case, we decided that base64 encoding would be best.) > > I'm not saying that this problem is cookie-related. It's just an > example of a situation where the application was the problem and we > didn't notice until Tomcat became more strict. Our application is > actually *safer* now because it is guaranteed to work with all clients > which strictly adhere to the specifications, while before it was > relying on sloppy interpretations[1] of the specifications and luckily > getting away with it. > > - -chris > > [1] https://whatwg.org/ > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3nvoQACgkQHPApP6U8 > pFhtKw/9FnbzlvWWVYuu+ao7fmleMdNb49elXhAPOTjCF0KAZgTvQlRx0ffhE5Kn > cZyJowghvOh2XLV16J5Q3UQcRulnU5RrAFNrsC/IysEXP6RzeqaYwjynZ0OpgO/K > Vbktg5v6qA6Ipje7UBvufC+WdeMede914JgBd1+aEqt4CQCi8mPbUJhnJcZyOPIL > k1nuxeGiX1pTt/wPG4yXnjnHe/MF/nMJznrxJuDMyPGd21hKfWwOzNyqTDAMRdpo > XZfNp46E5ucVRXJM9MK2WSf06I/gZhQmtXUerQ49Fn/rm+rY0HNTjV6qg+muTbB5 > LG+UfloW+Bf938DfMUiMx3Xbnc5CaVLCiwTH/hZzV9+aL4QA3wLG7py6dhWnOF4O > Xpilkc9npxLi205KmP1FU7/75U3IgQGRX7jxPdIxf9rYKOyDvEF8AY4cq0Uw/B/x > v47VZekkw0Ozhq0KwKrhmzu81T/u0+35DtCMj4LJl2hM8fEE4kBNBxibaTUDVYff > c6zjOaI3trDiD+D60i3Ir8lFLSWNK70u0L6ost85itPZUi9IYCZ1B2TURp17/al8 > n2BSvZFdME08AIbTXOaCP4J885xmzQJigtmDmqr5OCV9wPgOhAlFbTOgGc5tWdJu > TaiUNlyY1fCK38ZdWpagYiqF3RWIK4DU8Vds65aGO1tABMt6Niw= > =4Bb7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
