Re: encodeURL, jsessionid and mod_rewrite ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurent,

On 10/4/17 6:31 PM, Laurent Perez wrote:
> Obviously I'm thinking about renaming the war but the rewriting is
> really used, for example seo friendly urls like /bar/steps/1
> internally rewrite to /foo/somesubmodule/steps.jsp?step=1 and the
> system really can't expose /somesubmodule/steps.jsp?step=1 as
> public urls, it messes with google analytics stats or bookmarked
> urls.

Let's take a typical use-case, here, where you have a beautiful URL
that is lovely for SEO (which, by the way, seems like a fiction to me,
since search engines don't give flying fig about the value of the URL)
and makes flowers grow out of scrap metal.

Let's make that URL
https://example.com/what/a/great/url/just/gorgeous/hashtag/notsad

So you rewrite that URL internally to:

http://internal/RJdo10/8/2017/index.jsp?docId=5

Great, now the search engine has that nice URL and your application
has a pile of garbage to deal with. The user sees the nice URL and
they get their data. Awesome.

Now, what do the URLs look like on the actual page? They look like this:

Other pages you may like:

  Page 6
  Page 7
  Page 8
  Page 9
  Page 10


(Wasn't 1996 a great time to be on the web?)

When the search engine goes to index your page, it'll get your
beautiful URL from wherever it got it, but then it will get these
really ugly ones on the page, too. So your "Page 6" now has an
unsightly URL being leaked-out to your search engines.

How do you fix that?

Content-rewriting to the rescue! It'll be great, you can re-assign
each page to another beautiful URL:

PageID URL
6  https://example.com/astonishingly/well/written/URL
7  https://example.com/surpassed/our/previous/benchmark/for/beauty
8  https://example.com/getting/our/SEO/moneys/worth
9  https://example.com/CEOs/earn/every/penny
10 https://example.com/you/cant/make/this/stuff/up

So, now you get to maintain a huge list of "nice" URLs and their
mappings (in both directions!), plus you get the overhead of
re-writing 100% of the content of your page while it's streaming back
out to the client.

What about HTTP redirects?

Aw, shucks. Now we need to have another layer that checks all response
headers to see if we need to rewrite THOSE.

It becomes miserable, unwieldy, and generates huge amounts of excess
heat performing all of these (IMHO) completely useless operations.
What's the problem with the URL looking like
https://example.com/myapp/index.jsp?docId=5

Maybe I just don't "get" the whole concept of "SEO"... I figure if you
put content on your pages that doesn't suck and only contains the
words that make sense, you'll get the ranking you deserve. Playing
games with your URLs is just going to make more work for everyone.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnaYM8ACgkQHPApP6U8
pFj11Q//TVhBEm+kBhjt/tVi//NQ1I0ISLs02/F3A0t6fOgYv86j2IMgM9GLaIiS
yg5A5c/PIVIvcLfycssb8BWht9riVp0B8RVg8faeZkPnSCeK61dhylrPLwgKB7M4
eFoqZYKVqmKv0gMRSS3l+fAB0OKjM1LtBSBNpnJROeS5eIii3lOrACqFkiqCjy3p
NMsPB5b9eA9ZJPVtZMjARTndpqwSI/L44DcW+dwVveUvK6rXzXzqjy7G5MCDs6gM
ge51pqb9jd+oXd+Rnb6vKEN4JTn5mtDx7dKohpJDrqtFa0bwL1rxL5LLd/berFRD
dc4s0K2relxywWsVtrZfgCsuyqMJ9FAv/V9nZhB/Z8vq2WBep92pv9e1zXPF8Ijw
sbpx+23FKzOsIRe7o2Gj5yezEkno1Tgws1Q79W6TZZzsnRTOvrx2zdfrIh/e6zFC
XJBuU5cYdEYRIV1JbIzeupOyQdKc9B7KEgFWuaMOkT/T5peMXTGLZ+7+/TW1r2Mb
8vQVpQbIox3qa/0Xw+n0fts9zxZqHRpBgLv0UTL8Zr7keMgAWS3whYZQ05iS8cdd
W5Jnsl8ZeYWDeKzALwYgmWo3NdxBuHZJ7YuiB3XE1SeIpvQ3GLApBVabG+q205T2
B2d74VuioRgGMW6Gscu2zaGsQAjfFSoNxegGGChQBDqIZu9oU3g=
=NWa9
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[Mark Thomas]

On 4 October 2017 23:31:36 BST, Laurent Perez  wrote:
>Thanks for the replies. The jsessionid/cookie tracking mode is not
>really
>part of the problem, sorry about that.
>
>Obviously I'm thinking about renaming the war but the rewriting is
>really
>used, for example seo friendly urls like /bar/steps/1 internally
>rewrite to
>/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose
>/somesubmodule/steps.jsp?step=1 as public urls, it messes with google
>analytics stats or bookmarked urls.

Rewrites are not generally problematic. It is changing the context path that 
causes all the problems. Renaming foo.war to bar.war (or equivalent for you 
config) should be sufficient.

Mark


>
>As last resort I could move the apache RewriteRules to tuckey
>urlrewriter
>under the war itself and just keep the ProxyPasses under apache.
>Configuration & docs would be in a sole space.
>
>I know that just because I /can/ do nasty rewriting stuff at the
>response
>wrapper level I may not want to do it. The replies were useful ;)
>
>regards
>
>
>On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) 
>wrote:
>
>> On 04.10.2017 07:40, Peter Kreuser wrote:
>>
>>>
>>> Peter Kreuser
>>>
>>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz <
 ch...@christopherschultz.net>:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Laurant,

 On 10/3/17 5:17 PM, Laurent Perez wrote:
> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
> "foo" war is deployed at /foo context path under tomcat. The /foo
> path is not public, apache has a rewrite rule defined as : /bar/*
> rewrites internally to /foo/*.
>
> I'm using jstl and its  for every url in
>my
> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
> cookie is not yet set (1st requests)
>
>
>>> adding to Christopher, accepting the jsessionid from the Url is a
>bad
>>> security risk (Session fixation). So you should disable that by
>accepting
>>> the session only via COOKIE via
>>>
>>> COOKIE
>
>>> then at least this rewriting problem is gone.
>>>
>>> Peter
>>>
>>>
>> Well, a cookie can also be path-specific.  Which is only *one* of
>these
>> issues which we are talking about, when we say "don't".
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[Laurent Perez]

Thanks for the replies. The jsessionid/cookie tracking mode is not really
part of the problem, sorry about that.

Obviously I'm thinking about renaming the war but the rewriting is really
used, for example seo friendly urls like /bar/steps/1 internally rewrite to
/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose
/somesubmodule/steps.jsp?step=1 as public urls, it messes with google
analytics stats or bookmarked urls.

As last resort I could move the apache RewriteRules to tuckey urlrewriter
under the war itself and just keep the ProxyPasses under apache.
Configuration & docs would be in a sole space.

I know that just because I /can/ do nasty rewriting stuff at the response
wrapper level I may not want to do it. The replies were useful ;)

regards


On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) 
wrote:

> On 04.10.2017 07:40, Peter Kreuser wrote:
>
>>
>> Peter Kreuser
>>
>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz <
>>> ch...@christopherschultz.net>:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Laurant,
>>>
>>> On 10/3/17 5:17 PM, Laurent Perez wrote:
 I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
 "foo" war is deployed at /foo context path under tomcat. The /foo
 path is not public, apache has a rewrite rule defined as : /bar/*
 rewrites internally to /foo/*.

 I'm using jstl and its  for every url in my
 jsps to gain the ;jsessionid from encodeURL whenever jsessionid
 cookie is not yet set (1st requests)


>> adding to Christopher, accepting the jsessionid from the Url is a bad
>> security risk (Session fixation). So you should disable that by accepting
>> the session only via COOKIE via
>>
>> COOKIE 
>> then at least this rewriting problem is gone.
>>
>> Peter
>>
>>
> Well, a cookie can also be path-specific.  Which is only *one* of these
> issues which we are talking about, when we say "don't".
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
http://laurentperez.fr
J2EE, HTML5, JS, CSS3

Re: encodeURL, jsessionid and mod_rewrite ?

[tomcat]

On 04.10.2017 07:40, Peter Kreuser wrote:


Peter Kreuser


Am 04.10.2017 um 02:44 schrieb Christopher Schultz 
:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurant,


On 10/3/17 5:17 PM, Laurent Perez wrote:
I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
"foo" war is deployed at /foo context path under tomcat. The /foo
path is not public, apache has a rewrite rule defined as : /bar/*
rewrites internally to /foo/*.

I'm using jstl and its  for every url in my
jsps to gain the ;jsessionid from encodeURL whenever jsessionid
cookie is not yet set (1st requests)



adding to Christopher, accepting the jsessionid from the Url is a bad security 
risk (Session fixation). So you should disable that by accepting the session 
only via COOKIE via

COOKIE 
then at least this rewriting problem is gone.

Peter



Well, a cookie can also be path-specific.  Which is only *one* of these issues which we 
are talking about, when we say "don't".




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[tomcat]

On 04.10.2017 02:44, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurant,

On 10/3/17 5:17 PM, Laurent Perez wrote:

I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
"foo" war is deployed at /foo context path under tomcat. The /foo
path is not public, apache has a rewrite rule defined as : /bar/*
rewrites internally to /foo/*.

I'm using jstl and its  for every url in my
jsps to gain the ;jsessionid from encodeURL whenever jsessionid
cookie is not yet set (1st requests)

Now my question is : the  results in a
"/foo/page.jsp;jsessionid=..." I want the result instead as
/bar/pages.jsp;jsessionid=

Should I go straight for a HttpServletResponseWrapper replacing
every /foo/ with /bar/ or is there a more elegant way ? If the
apache rewrite rule is modified - say, to /barv2/, is it ok to use
mod_headers to pass the original path instead of hardcoding /bar/
?


You are going down a path that will produce endless problems, hacks,
and ugly solutions to those problems. It will be much easier for you
to simply re-name your application from "foo" to "bar" and not worry
about any of this rewriting foolishness.

- -chris


+1.
I can only agree 100% with what Chris is saying above.
The fact that you /can/ do these things at the front-end proxy level, does not mean that 
it is a good idea to do it.  There are probably cases when you can *really* not do 
otherwise, and that's why these mechanisms are there.
But doing this, brings endless other practical inconvenients, extra work, confusion, 
documentation issues, understanding issues 6 months later, support issues, etc.

So, in a nutshell : don't do it.

P.S. The annoying bit about recommendations such as the above, is that if you follow them, 
you will not even know how much work and hassle you have saved to yourself, and

1) you will not even feel thankful
and
2) we won't have the satisfaction of saying later : "well, we told you so"
;-)



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[Mark Thomas]

On 4 October 2017 06:40:24 BST, Peter Kreuser  wrote:
>
>Peter Kreuser
>
>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz
>:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Laurant,
>> 
>>> On 10/3/17 5:17 PM, Laurent Perez wrote:
>>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>>> "foo" war is deployed at /foo context path under tomcat. The /foo
>>> path is not public, apache has a rewrite rule defined as : /bar/* 
>>> rewrites internally to /foo/*.
>>> 
>>> I'm using jstl and its  for every url in my
>>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>>> cookie is not yet set (1st requests)
>>> 
>
>adding to Christopher, accepting the jsessionid from the Url is a bad
>security risk (Session fixation). So you should disable that by
>accepting the session only via COOKIE via
>
>COOKIE 
>then at least this rewriting problem is gone.

... to be exchanged for a problem with the cookie path.


>>> Now my question is : the  results in a
>>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>>> /bar/pages.jsp;jsessionid=
>>> 
>>> Should I go straight for a HttpServletResponseWrapper replacing
>>> every /foo/ with /bar/ or is there a more elegant way ? If the
>>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>>> mod_headers to pass the original path instead of hardcoding /bar/
>>> ?
>> 
>> You are going down a path that will produce endless problems, hacks,
>> and ugly solutions to those problems. It will be much easier for you
>> to simply re-name your application from "foo" to "bar" and not worry
>> about any of this rewriting foolishness.

Huge +1

Mark


>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
>> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
>> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
>> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
>> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
>> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
>> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
>> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
>> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
>> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
>> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
>> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
>> =0zb2
>> -END PGP SIGNATURE-
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: encodeURL, jsessionid and mod_rewrite ?

[Peter Kreuser]

Peter Kreuser

> Am 04.10.2017 um 02:44 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Laurant,
> 
>> On 10/3/17 5:17 PM, Laurent Perez wrote:
>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>> "foo" war is deployed at /foo context path under tomcat. The /foo
>> path is not public, apache has a rewrite rule defined as : /bar/* 
>> rewrites internally to /foo/*.
>> 
>> I'm using jstl and its  for every url in my
>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>> cookie is not yet set (1st requests)
>> 

adding to Christopher, accepting the jsessionid from the Url is a bad security 
risk (Session fixation). So you should disable that by accepting the session 
only via COOKIE via

COOKIE 
then at least this rewriting problem is gone.

Peter

>> Now my question is : the  results in a
>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>> /bar/pages.jsp;jsessionid=
>> 
>> Should I go straight for a HttpServletResponseWrapper replacing
>> every /foo/ with /bar/ or is there a more elegant way ? If the
>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>> mod_headers to pass the original path instead of hardcoding /bar/
>> ?
> 
> You are going down a path that will produce endless problems, hacks,
> and ugly solutions to those problems. It will be much easier for you
> to simply re-name your application from "foo" to "bar" and not worry
> about any of this rewriting foolishness.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
> =0zb2
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: encodeURL, jsessionid and mod_rewrite ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurant,

On 10/3/17 5:17 PM, Laurent Perez wrote:
> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
> "foo" war is deployed at /foo context path under tomcat. The /foo
> path is not public, apache has a rewrite rule defined as : /bar/* 
> rewrites internally to /foo/*.
> 
> I'm using jstl and its  for every url in my
> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
> cookie is not yet set (1st requests)
> 
> Now my question is : the  results in a
> "/foo/page.jsp;jsessionid=..." I want the result instead as
> /bar/pages.jsp;jsessionid=
> 
> Should I go straight for a HttpServletResponseWrapper replacing
> every /foo/ with /bar/ or is there a more elegant way ? If the
> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
> mod_headers to pass the original path instead of hardcoding /bar/
> ?

You are going down a path that will produce endless problems, hacks,
and ugly solutions to those problems. It will be much easier for you
to simply re-name your application from "foo" to "bar" and not worry
about any of this rewriting foolishness.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
/LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
j/5ZMvfJiUZdDAdQxoFH6B9ochU=
=0zb2
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org