Well this isn't an issue with Tomcat. I'm using an embedded version of Tomcat in the BeAPI API Toolkit and this does not occur; mainly because it automates 100% of the api functionality. I would say it is most likely your application.
How are you testing your app? You should be doing integration tests. This would show the issue or problem in the response data vs what is sent. Owen Rubel oru...@gmail.com On Sat, Dec 7, 2019 at 3:11 AM thulasiram k <ktr...@gmail.com> wrote: > 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 > > > > >
