You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Erik Bunn <eb...@memecry.net> on 2010/07/30 18:19:12 UTC
Re: UTF-8 encoding in Tomcat 6.0
Hi -
This may be irrelevant to the original asker by now, and I'm working
with Tomcat 7, but in case it's of use:
Christopher Schultz, Wed, 21 Apr 2010 08:43:57 -0700 wrote:
> The filter cannot influence the way that GET parameters are decoded. The
> only way to change that is to set URIEncoding="UTF-8" on your <Connector> in
> server.xml.
This is, at least in some special cases, incorrect: based on quite a bit
of Tomcat 7.0b embedding effort recently, I tracked this same issue all
the way through, and Tomcat defaults to ISO-8859-1 if the request does
not specify content-type explicitly, despite whatever Connector settings.
See e.g. CoyoteAdapter.parsePathParameters() for an example.
(A request without content-type happens e.g. in Firefox 3.6 with a
dynamically created script DOM element to an external URL; I'm sure
there are other occasions as well.)
The only way I found around it was to have my own Connector
implementation provide my own Request wrapper, and override
getCharacterEncoding() there based on the URIEncoding setting.
(Not very user-friendly; I imagine it's doable with the standard
configuration scheme, but I can't help with that - sorry. Feel
free to email if you need pointers, anyway.)
Cheers,
//e
Re: UTF-8 encoding in Tomcat 6.0
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Erik,
On 7/30/2010 1:55 PM, Erik Bunn wrote:
> 7.x Connector has the exact same options. I'll restate, though, that
> setting the Connector URIEncoding in TC7.x won't currently help when
> decoding GET parameters in a no-content-type case - without the
> filter, they will be mangled as ISO-8859-1. If this is different from
> previous behaviour, maybe I should report a bug.
It works perfectly well for me when using URIEncoding="UTF-8".
The Content-Type of the request is never consulted for any reason in
this case, so its presence should not change anything as you indicate above.
Can you give us a repeatable example?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxZsggACgkQ9CaO5/Lv0PCcNwCgo6fRS4vA5VsbMtrGGx1MwY/r
uQEAoK97EqwJFtp77yOSaeHUD6gtGh5a
=6RL/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: UTF-8 encoding in Tomcat 6.0
Posted by Mark Thomas <ma...@apache.org>.
On 31/07/2010 17:34, arun kumar wrote:
>
> I ran my example webapp on a standalone tomcat and the behavior was the same:
> When the param is being sent using GET, I need to send the param as %25xx for it to be read correctly
> When the method is PUT, %xx works fine.
Then something in your setup is badly broken, evidenced by the fact you
have to encode the % as %25 to get things to work.
> I believe this is a known issue with Tomcat: I remember reading this on many forums. I believe this is the same behavior that Erik reports.
This is absolutely *not* a Tomcat problem. Tomcat does not behave the
way you describe. A clean Tomcat install with no other components
(reverse proxy etc) using the test encoding JSP from the wiki [1] works
correctly with POST and GET (if URIEncoding="UTF-8" is used).
> Sorry Mark - i did not get what you said. Could you please elaborate?
Decoding is happening twice. i.e.:
%25xx -> %xx
%xx -> whatever character
Tomcat absolutely, 100% does not do this. Either your test application
is doing it or there is another component - such as a reverse proxy - in
the mix that is doing a second decoding.
This represents a significant security risks. Issues caused by double
decoding in the past include:
- XSS
- source code disclosure
- authentication bypass
- directory traversal
It does not mean that these issues will be present, but double decoding
has been the cause of all of these - and probably more - at various
points in the past. The details will depend on system configuration but
seeing an issue like this is certainly indicative that there may well be
a problem.
Mark
[1] http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4
> Regards
> Arun
>
> --- On Sat, 7/31/10, Mark Thomas <ma...@apache.org> wrote:
>
>> From: Mark Thomas <ma...@apache.org>
>> Subject: Re: UTF-8 encoding in Tomcat 6.0
>> To: "Tomcat Users List" <us...@tomcat.apache.org>
>> Date: Saturday, July 31, 2010, 12:18 PM
>> On 31/07/2010 15:40, arun kumar
>> wrote:
>>> Hi Erik
>>> Thanks very much for your responses.
>>> I can assure that i'm interested in this topic even
>> now :).
>>>
>>> My scenario is this:
>>>
>>> 1. I use a web application that runs in JBOSS.
>>>
>>> 2. JBOSS uses a tomcat web container from what i can
>> see.
>>>
>>> 3. To my application if i pass a UTF-8 encoded value
>> in hex e.g:
>>>
>> http://<server>:<port>/<servlet>/param=%xx...
>>>
>>> Then %xx is not decoded properly. I initially used to
>> send the request with a mozilla browser but later started
>> sending it with a java program as well with the same
>> results.
>>>
>>> I tried setting the URI Encoding parameters in the
>> tomcat server.xml - with no success.
>>> I then set a filter to specifically set the encoding
>> to utf-8 - again with no luck - behavior was exactly the
>> same.
>>>
>>> But when i sent the param as %25xx ( %25= hex value of
>> the % character), it worked fine but i suspect that the
>> string gets stored in ISO 8859 format - like you say: it
>> gets mangled...
>>
>> That smells of double-decoding which as well as breaking
>> your app is
>> also a security risk. I have seen this when a reverse proxy
>> is in the mix.
>>
>> Tomcat will *not* do this on its own.
>>
>> Mark
>>
>>
>>
>>> I wrote a standalone web application that showed the
>> same behavior.
>>> I haven't tried with a standalone tomcat.
>>>
>>> I know that we need to take care of the encodings at
>> various points but how can i rule out a problem with
>> my web container configuration settings? Or can it be a
>> problem coming from the web container itself?
>>>
>>> Thanks and regards
>>> Arun
>>>
>>>
>>> --- On Fri, 7/30/10, Erik Bunn <eb...@memecry.net>
>> wrote:
>>>
>>>> From: Erik Bunn <eb...@memecry.net>
>>>> Subject: Re: UTF-8 encoding in Tomcat 6.0
>>>> To: "Tomcat Users List" <us...@tomcat.apache.org>
>>>> Date: Friday, July 30, 2010, 1:55 PM
>>>> On 7/30/10 6:33 PM, Christopher
>>>> Schultz wrote:
>>>>
>>>>> If all you want to do is set the character
>> encoding,
>>>> you can easily call
>>>>> setCharacterEncoding and be done with it:
>> subclassing
>>>> and overriding
>>>>> should not be necessary at all, otherwise
>> nobody would
>>>> have written one
>>>>> of these:
>>>>
>>>> No, I have other reasons to mess there.
>> Nevertheless,
>>>> adding a filter is
>>>> probably less iffy, thanks for pointing that out.
>> TC7
>>>> provides a suitable
>>>> example:
>>>>
>> .../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
>>>>
>>>>> Tomcat versions before 7.x had an option in
>>>> the<Connector> which could
>>>>> be used to set the request URI encoding to
>> that of the
>>>> Content-Type of
>>>>> the request (useBodyEncodingForURI) and
>> another option
>>>> for explicitly
>>>>> and unconditionally setting the encoding to be
>> used
>>>> for URI decoding
>>>>> (URIEncoding). I haven't read-up on Tomcat 7
>>>> behavior.
>>>>
>>>> 7.x Connector has the exact same options. I'll
>> restate,
>>>> though, that setting
>>>> the Connector URIEncoding in TC7.x won't currently
>> help
>>>> when decoding GET
>>>> parameters in a no-content-type case - without the
>> filter,
>>>> they will be
>>>> mangled as ISO-8859-1. If this is different from
>> previous
>>>> behaviour, maybe I
>>>> should report a bug.
>>>>
>>>> Thanks,
>>>> //e
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: UTF-8 encoding in Tomcat 6.0
Posted by arun kumar <ar...@yahoo.com>.
I ran my example webapp on a standalone tomcat and the behavior was the same:
When the param is being sent using GET, I need to send the param as %25xx for it to be read correctly
When the method is PUT, %xx works fine.
I believe this is a known issue with Tomcat: I remember reading this on many forums. I believe this is the same behavior that Erik reports.
Sorry Mark - i did not get what you said. Could you please elaborate?
Regards
Arun
--- On Sat, 7/31/10, Mark Thomas <ma...@apache.org> wrote:
> From: Mark Thomas <ma...@apache.org>
> Subject: Re: UTF-8 encoding in Tomcat 6.0
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Saturday, July 31, 2010, 12:18 PM
> On 31/07/2010 15:40, arun kumar
> wrote:
> > Hi Erik
> > Thanks very much for your responses.
> > I can assure that i'm interested in this topic even
> now :).
> >
> > My scenario is this:
> >
> > 1. I use a web application that runs in JBOSS.
> >
> > 2. JBOSS uses a tomcat web container from what i can
> see.
> >
> > 3. To my application if i pass a UTF-8 encoded value
> in hex e.g:
> >
> http://<server>:<port>/<servlet>/param=%xx...
> >
> > Then %xx is not decoded properly. I initially used to
> send the request with a mozilla browser but later started
> sending it with a java program as well with the same
> results.
> >
> > I tried setting the URI Encoding parameters in the
> tomcat server.xml - with no success.
> > I then set a filter to specifically set the encoding
> to utf-8 - again with no luck - behavior was exactly the
> same.
> >
> > But when i sent the param as %25xx ( %25= hex value of
> the % character), it worked fine but i suspect that the
> string gets stored in ISO 8859 format - like you say: it
> gets mangled...
>
> That smells of double-decoding which as well as breaking
> your app is
> also a security risk. I have seen this when a reverse proxy
> is in the mix.
>
> Tomcat will *not* do this on its own.
>
> Mark
>
>
>
> > I wrote a standalone web application that showed the
> same behavior.
> > I haven't tried with a standalone tomcat.
> >
> > I know that we need to take care of the encodings at
> various points but how can i rule out a problem with
> my web container configuration settings? Or can it be a
> problem coming from the web container itself?
> >
> > Thanks and regards
> > Arun
> >
> >
> > --- On Fri, 7/30/10, Erik Bunn <eb...@memecry.net>
> wrote:
> >
> >> From: Erik Bunn <eb...@memecry.net>
> >> Subject: Re: UTF-8 encoding in Tomcat 6.0
> >> To: "Tomcat Users List" <us...@tomcat.apache.org>
> >> Date: Friday, July 30, 2010, 1:55 PM
> >> On 7/30/10 6:33 PM, Christopher
> >> Schultz wrote:
> >>
> >>> If all you want to do is set the character
> encoding,
> >> you can easily call
> >>> setCharacterEncoding and be done with it:
> subclassing
> >> and overriding
> >>> should not be necessary at all, otherwise
> nobody would
> >> have written one
> >>> of these:
> >>
> >> No, I have other reasons to mess there.
> Nevertheless,
> >> adding a filter is
> >> probably less iffy, thanks for pointing that out.
> TC7
> >> provides a suitable
> >> example:
> >>
> .../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
> >>
> >>> Tomcat versions before 7.x had an option in
> >> the<Connector> which could
> >>> be used to set the request URI encoding to
> that of the
> >> Content-Type of
> >>> the request (useBodyEncodingForURI) and
> another option
> >> for explicitly
> >>> and unconditionally setting the encoding to be
> used
> >> for URI decoding
> >>> (URIEncoding). I haven't read-up on Tomcat 7
> >> behavior.
> >>
> >> 7.x Connector has the exact same options. I'll
> restate,
> >> though, that setting
> >> the Connector URIEncoding in TC7.x won't currently
> help
> >> when decoding GET
> >> parameters in a no-content-type case - without the
> filter,
> >> they will be
> >> mangled as ISO-8859-1. If this is different from
> previous
> >> behaviour, maybe I
> >> should report a bug.
> >>
> >> Thanks,
> >> //e
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: UTF-8 encoding in Tomcat 6.0
Posted by Mark Thomas <ma...@apache.org>.
On 31/07/2010 15:40, arun kumar wrote:
> Hi Erik
> Thanks very much for your responses.
> I can assure that i'm interested in this topic even now :).
>
> My scenario is this:
>
> 1. I use a web application that runs in JBOSS.
>
> 2. JBOSS uses a tomcat web container from what i can see.
>
> 3. To my application if i pass a UTF-8 encoded value in hex e.g:
> http://<server>:<port>/<servlet>/param=%xx...
>
> Then %xx is not decoded properly. I initially used to send the request with a mozilla browser but later started sending it with a java program as well with the same results.
>
> I tried setting the URI Encoding parameters in the tomcat server.xml - with no success.
> I then set a filter to specifically set the encoding to utf-8 - again with no luck - behavior was exactly the same.
>
> But when i sent the param as %25xx ( %25= hex value of the % character), it worked fine but i suspect that the string gets stored in ISO 8859 format - like you say: it gets mangled...
That smells of double-decoding which as well as breaking your app is
also a security risk. I have seen this when a reverse proxy is in the mix.
Tomcat will *not* do this on its own.
Mark
> I wrote a standalone web application that showed the same behavior.
> I haven't tried with a standalone tomcat.
>
> I know that we need to take care of the encodings at various points but how can i rule out a problem with my web container configuration settings? Or can it be a problem coming from the web container itself?
>
> Thanks and regards
> Arun
>
>
> --- On Fri, 7/30/10, Erik Bunn <eb...@memecry.net> wrote:
>
>> From: Erik Bunn <eb...@memecry.net>
>> Subject: Re: UTF-8 encoding in Tomcat 6.0
>> To: "Tomcat Users List" <us...@tomcat.apache.org>
>> Date: Friday, July 30, 2010, 1:55 PM
>> On 7/30/10 6:33 PM, Christopher
>> Schultz wrote:
>>
>>> If all you want to do is set the character encoding,
>> you can easily call
>>> setCharacterEncoding and be done with it: subclassing
>> and overriding
>>> should not be necessary at all, otherwise nobody would
>> have written one
>>> of these:
>>
>> No, I have other reasons to mess there. Nevertheless,
>> adding a filter is
>> probably less iffy, thanks for pointing that out. TC7
>> provides a suitable
>> example:
>> .../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
>>
>>> Tomcat versions before 7.x had an option in
>> the<Connector> which could
>>> be used to set the request URI encoding to that of the
>> Content-Type of
>>> the request (useBodyEncodingForURI) and another option
>> for explicitly
>>> and unconditionally setting the encoding to be used
>> for URI decoding
>>> (URIEncoding). I haven't read-up on Tomcat 7
>> behavior.
>>
>> 7.x Connector has the exact same options. I'll restate,
>> though, that setting
>> the Connector URIEncoding in TC7.x won't currently help
>> when decoding GET
>> parameters in a no-content-type case - without the filter,
>> they will be
>> mangled as ISO-8859-1. If this is different from previous
>> behaviour, maybe I
>> should report a bug.
>>
>> Thanks,
>> //e
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: UTF-8 encoding in Tomcat 6.0
Posted by arun kumar <ar...@yahoo.com>.
Hi Erik
Thanks very much for your responses.
I can assure that i'm interested in this topic even now :).
My scenario is this:
1. I use a web application that runs in JBOSS.
2. JBOSS uses a tomcat web container from what i can see.
3. To my application if i pass a UTF-8 encoded value in hex e.g:
http://<server>:<port>/<servlet>/param=%xx...
Then %xx is not decoded properly. I initially used to send the request with a mozilla browser but later started sending it with a java program as well with the same results.
I tried setting the URI Encoding parameters in the tomcat server.xml - with no success.
I then set a filter to specifically set the encoding to utf-8 - again with no luck - behavior was exactly the same.
But when i sent the param as %25xx ( %25= hex value of the % character), it worked fine but i suspect that the string gets stored in ISO 8859 format - like you say: it gets mangled...
I wrote a standalone web application that showed the same behavior.
I haven't tried with a standalone tomcat.
I know that we need to take care of the encodings at various points but how can i rule out a problem with my web container configuration settings? Or can it be a problem coming from the web container itself?
Thanks and regards
Arun
--- On Fri, 7/30/10, Erik Bunn <eb...@memecry.net> wrote:
> From: Erik Bunn <eb...@memecry.net>
> Subject: Re: UTF-8 encoding in Tomcat 6.0
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Friday, July 30, 2010, 1:55 PM
> On 7/30/10 6:33 PM, Christopher
> Schultz wrote:
>
> > If all you want to do is set the character encoding,
> you can easily call
> > setCharacterEncoding and be done with it: subclassing
> and overriding
> > should not be necessary at all, otherwise nobody would
> have written one
> > of these:
>
> No, I have other reasons to mess there. Nevertheless,
> adding a filter is
> probably less iffy, thanks for pointing that out. TC7
> provides a suitable
> example:
> .../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
>
> > Tomcat versions before 7.x had an option in
> the<Connector> which could
> > be used to set the request URI encoding to that of the
> Content-Type of
> > the request (useBodyEncodingForURI) and another option
> for explicitly
> > and unconditionally setting the encoding to be used
> for URI decoding
> > (URIEncoding). I haven't read-up on Tomcat 7
> behavior.
>
> 7.x Connector has the exact same options. I'll restate,
> though, that setting
> the Connector URIEncoding in TC7.x won't currently help
> when decoding GET
> parameters in a no-content-type case - without the filter,
> they will be
> mangled as ISO-8859-1. If this is different from previous
> behaviour, maybe I
> should report a bug.
>
> Thanks,
> //e
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: UTF-8 encoding in Tomcat 6.0
Posted by Erik Bunn <eb...@memecry.net>.
On 7/30/10 6:33 PM, Christopher Schultz wrote:
> If all you want to do is set the character encoding, you can easily call
> setCharacterEncoding and be done with it: subclassing and overriding
> should not be necessary at all, otherwise nobody would have written one
> of these:
No, I have other reasons to mess there. Nevertheless, adding a filter is
probably less iffy, thanks for pointing that out. TC7 provides a suitable
example:
.../webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java
> Tomcat versions before 7.x had an option in the<Connector> which could
> be used to set the request URI encoding to that of the Content-Type of
> the request (useBodyEncodingForURI) and another option for explicitly
> and unconditionally setting the encoding to be used for URI decoding
> (URIEncoding). I haven't read-up on Tomcat 7 behavior.
7.x Connector has the exact same options. I'll restate, though, that setting
the Connector URIEncoding in TC7.x won't currently help when decoding GET
parameters in a no-content-type case - without the filter, they will be
mangled as ISO-8859-1. If this is different from previous behaviour, maybe I
should report a bug.
Thanks,
//e
Re: UTF-8 encoding in Tomcat 6.0
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Erik,
On 7/30/2010 12:19 PM, Erik Bunn wrote:
> Christopher Schultz, Wed, 21 Apr 2010 08:43:57 -0700 wrote:
>> The filter cannot influence the way that GET parameters are decoded. The
>> only way to change that is to set URIEncoding="UTF-8" on your
>> <Connector> in
>> server.xml.
>
> This is, at least in some special cases, incorrect: based on quite a bit
> of Tomcat 7.0b embedding effort recently, I tracked this same issue all
> the way through, and Tomcat defaults to ISO-8859-1 if the request does
> not specify content-type explicitly, despite whatever Connector settings.
> See e.g. CoyoteAdapter.parsePathParameters() for an example.
>
> (A request without content-type happens e.g. in Firefox 3.6 with a
> dynamically created script DOM element to an external URL; I'm sure
> there are other occasions as well.)
This has nothing to do with the Content-Type HTTP header, which governs
the character encoding of the request body. Instead, it has to do with
the character encoding of the request /URI/, for which there is no
widespread standard for explicitly indicating in the request.
Tomcat versions before 7.x had an option in the <Connector> which could
be used to set the request URI encoding to that of the Content-Type of
the request (useBodyEncodingForURI) and another option for explicitly
and unconditionally setting the encoding to be used for URI decoding
(URIEncoding). I haven't read-up on Tomcat 7 behavior.
> The only way I found around it was to have my own Connector
> implementation provide my own Request wrapper, and override
> getCharacterEncoding() there based on the URIEncoding setting.
> (Not very user-friendly; I imagine it's doable with the standard
> configuration scheme, but I can't help with that - sorry. Feel
> free to email if you need pointers, anyway.)
Again, the getCharacterEncoding method on the request dictates the
encoding used to decode the request body, not the request URI.
If all you want to do is set the character encoding, you can easily call
setCharacterEncoding and be done with it: subclassing and overriding
should not be necessary at all, otherwise nobody would have written one
of these:
http://www.google.com/search?q=characterencodingfilter
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxS/twACgkQ9CaO5/Lv0PAh7QCeN4B/N7+iq/TcEv+QewcLV/5O
Hb0AniwHt0EDHqlKl67v7nD6VoqoU+X3
=W9t4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org