You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by thulasiram k <kt...@gmail.com> on 2019/12/04 11:02:46 UTC
Error parsing HTTP request header
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(InternalInputBuffer.java:199)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1050)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:319)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.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.
Thanks
Ram
Re: Error parsing HTTP request header
Posted by ktrwas <kt...@gmail.com>.
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 <or...@gmail.com> Date: 12/8/19 09:12 (GMT+05:30) To: Tomcat Users List <us...@tomcat.apache.org> Cc: chris@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 <kt...@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 <> chris@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-unsubscribe@tomcat.apache.org> > For additional commands, e-mail: users-help@tomcat.apache.org> >> >>
Re: Error parsing HTTP request header
Posted by Owen Rubel <or...@gmail.com>.
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
orubel@gmail.com
On Sat, Dec 7, 2019 at 3:11 AM thulasiram k <kt...@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 <
> chris@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
Re: Error parsing HTTP request header
Posted by thulasiram k <kt...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Error parsing HTTP request header
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org