Hi Owen,The same code was deployed in 7.0.91 version and we were not getting
any exceptions in tomcat logs. Once I deployed the same code in 7.0.94 it
started recording this error in logs.ThanksRamSent from my Samsung Galaxy
smartphone.
-------- Original message --------From: Owen Rubel <oru...@gmail.com> Date:
12/8/19 09:12 (GMT+05:30) To: Tomcat Users List <users@tomcat.apache.org> Cc:
ch...@christopherschultz.net Subject: Re: Error parsing HTTP request header
Well this isn't an issue with Tomcat. I'm using an embedded version ofTomcat in
the BeAPI API Toolkit and this does not occur; mainly because itautomates 100%
of the api functionality. I would say it is most likely yourapplication.How are
you testing your app? You should be doing integration tests. Thiswould show the
issue or problem in the response data vs what is sent.Owen
Rubelorubel@gmail.comOn 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> >> >>
