Tomcat 8/Redhat Linux 6.6 /Kernal 2.6.32 - Memory Won't Release

[Eric Chua]

I am running tomcat 8.0.121.  When I start my tomcat, it seems to be eating up 
all the memory on my system.  I have 16 GB, and it keeps on going.  Then when I 
try to kill the process, it dies but 12 GB is still being used even though 
everything is turn off.  The only way to reclaim the memory is to reboot.  I am 
running on redhat 6.5 and can't figure out what could be causing this.  I run 
the tomcat as a local user, and I know there aren't any other processes running 
as the local user.  I am running a spring MVC 4/Java 8/ struts web application. 
I have two of them with the same issue.  Any help would be appreciated. When I 
try to view all the running processes I cannot see where most of the 12 gb are 
being used.   The system came up with 2.2 gb used and after I start one web 
application it goes to 14-15gb.   The funny thing is that I can kill it to 
reclaim the memory. Only a reboot works.  I am running a VMware instance with 
vcenter version 6.5.  This does not happen with Java 7 with tomcat 7. Any help 
would be appreciate.

Re: Syntax change in Set-Cookie header?

[Jim Griswold]

Sure, will do!


Jim

On Thu, Mar 16, 2017 at 12:57 PM, Mark Thomas  wrote:

> On 16 March 2017 14:31:31 GMT+00:00, Jim Griswold 
> wrote:
> >Thanks, Mark! I filed
> >https://bz.apache.org/bugzilla/show_bug.cgi?id=60876
>
> Thanks. I don't suppose you'd like to try your hand at a patch?
>
> Mark
>
>
> >
> >
> >Jim
> >
> >On Thu, Mar 16, 2017 at 6:15 AM, Mark Thomas  wrote:
> >
> >> On 15/03/17 21:56, Jim Griswold wrote:
> >> > Hi everyone,
> >> >
> >> > After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a
> >> syntax
> >> > change in the Set-Cookie header generated by Tomcat, and I was
> >hoping to
> >> > confirm whether this is intentional or if I'm doing something
> >> incorrectly.
> >> >
> >> > The background:
> >> >
> >> > After upgrading Tomcat, some automated tests started failing. These
> >tests
> >> > use an Apache CXF client to make requests to a service running
> >inside
> >> > Tomcat, and then make various assertions on the value of the
> >Set-Cookie
> >> > header returned from from the service.
> >> >
> >> > The root cause of the failure appears to be a change in the syntax
> >used
> >> for
> >> > the Set-Cookie header which resulted in parsing failures in the
> >client.
> >> >
> >> > The header that's generated by Tomcat 8.0.28 looks like:
> >> >
> >> > Set-Cookie: cookie_name=value; Path=/
> >> >
> >> > With 8.5.11, it looks like:
> >> >
> >> > Set-Cookie: cookie_name=value;path=/
> >> >
> >> > Note the missing space after the semicolon and the change from
> >"Path" to
> >> > "path". After some digging around, I saw that the
> >> > new Rfc6265CookieProcessor was changed to be the default cookie
> >> processor.
> >> > When I followed instructions [1] to change back to the old
> >processor, the
> >> > original behavior was restored and my tests pass again.
> >> >
> >> > Is this expected behavior? I see that RFC 6265 specifies [2] that
> >there
> >> > must be a space between the semicolon and "path", and that it
> >should be
> >> > "Path" with the first letter uppercased. Taking a look at the
> >> > Rfc6265CookieProcessor source code (the generateHeader method,
> >> > specifically), the lack of space and lower case p appear to be
> >> intentional,
> >> > yet don't seem to conform to the RFC the class is targeting.
> >> >
> >> > I am sure I must be missing something since this is the new default
> >and
> >> > this is such a common behavior, but I've dug around for a while and
> >can't
> >> > find another explanation.
> >>
> >> Those are implementation bugs. Please raise a Bugzilla issue. The
> >case
> >> issue is probably wider than just path.
> >>
> >> Reading through the rest of the spec, they both look to be things
> >> clients should tolerate so you probably want to look at the client
> >code
> >> as well.
> >>
> >> Kind regards,
> >>
> >> Mark
> >>
> >>
> >> >
> >> > Thanks in advance for your time and help!
> >> >
> >> > Jim
> >> >
> >> > [1]
> >> > http://stackoverflow.com/questions/38696081/how-to-
> >> change-cookie-processor-to-legacycookieprocessor-in-tomcat-8
> >> >
> >> > [2] https://tools.ietf.org/html/rfc6265#section-4.1.1
> >> >
> >>
> >>
> >> -
> >> 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: Syntax change in Set-Cookie header?

[Mark Thomas]

On 16 March 2017 14:31:31 GMT+00:00, Jim Griswold  
wrote:
>Thanks, Mark! I filed
>https://bz.apache.org/bugzilla/show_bug.cgi?id=60876

Thanks. I don't suppose you'd like to try your hand at a patch?

Mark


>
>
>Jim
>
>On Thu, Mar 16, 2017 at 6:15 AM, Mark Thomas  wrote:
>
>> On 15/03/17 21:56, Jim Griswold wrote:
>> > Hi everyone,
>> >
>> > After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a
>> syntax
>> > change in the Set-Cookie header generated by Tomcat, and I was
>hoping to
>> > confirm whether this is intentional or if I'm doing something
>> incorrectly.
>> >
>> > The background:
>> >
>> > After upgrading Tomcat, some automated tests started failing. These
>tests
>> > use an Apache CXF client to make requests to a service running
>inside
>> > Tomcat, and then make various assertions on the value of the
>Set-Cookie
>> > header returned from from the service.
>> >
>> > The root cause of the failure appears to be a change in the syntax
>used
>> for
>> > the Set-Cookie header which resulted in parsing failures in the
>client.
>> >
>> > The header that's generated by Tomcat 8.0.28 looks like:
>> >
>> > Set-Cookie: cookie_name=value; Path=/
>> >
>> > With 8.5.11, it looks like:
>> >
>> > Set-Cookie: cookie_name=value;path=/
>> >
>> > Note the missing space after the semicolon and the change from
>"Path" to
>> > "path". After some digging around, I saw that the
>> > new Rfc6265CookieProcessor was changed to be the default cookie
>> processor.
>> > When I followed instructions [1] to change back to the old
>processor, the
>> > original behavior was restored and my tests pass again.
>> >
>> > Is this expected behavior? I see that RFC 6265 specifies [2] that
>there
>> > must be a space between the semicolon and "path", and that it
>should be
>> > "Path" with the first letter uppercased. Taking a look at the
>> > Rfc6265CookieProcessor source code (the generateHeader method,
>> > specifically), the lack of space and lower case p appear to be
>> intentional,
>> > yet don't seem to conform to the RFC the class is targeting.
>> >
>> > I am sure I must be missing something since this is the new default
>and
>> > this is such a common behavior, but I've dug around for a while and
>can't
>> > find another explanation.
>>
>> Those are implementation bugs. Please raise a Bugzilla issue. The
>case
>> issue is probably wider than just path.
>>
>> Reading through the rest of the spec, they both look to be things
>> clients should tolerate so you probably want to look at the client
>code
>> as well.
>>
>> Kind regards,
>>
>> Mark
>>
>>
>> >
>> > Thanks in advance for your time and help!
>> >
>> > Jim
>> >
>> > [1]
>> > http://stackoverflow.com/questions/38696081/how-to-
>> change-cookie-processor-to-legacycookieprocessor-in-tomcat-8
>> >
>> > [2] https://tools.ietf.org/html/rfc6265#section-4.1.1
>> >
>>
>>
>> -
>> 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: CVEs Not Published

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 3/16/17 10:25 AM, David Dillard wrote:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816

I was working on updating this one. I've sent a notification to Mitre
with all the details.

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

iQIcBAEBCAAGBQJYyqj9AAoJEBzwKT+lPKRYsoMP/1Np1duQWNaV1QSQvC76rOiy
GT5qH8ZBBdk+CWa0Kg7Vly8xnhhYCIgH89zUP+t+kLXSWeb4l50eNuQ09ZflcdIs
Iq01A72Zz7LybpGMA1rZa0QmsWwtVxIO6LcI3SpVsDaKZMmZfvTIQbk2u5JyWElW
MSn5Hm5KQHY8zMyDqiZK2jJ2QR/xjfKmqF18/eBAW1F0Qog5zNTGtTUIPrEPIHTF
ThCROkbnDmjmnWKboti7SWcLk1YfpL4ttD5x9okkGekYyVWdzyB0TgQL/UXQBKeO
KESD5hZR17bUdtxzzJ1k9imYM/zfSS1BG+cA9ZFW6wfM461dulotX1XOj28AG/OJ
GsMA3/Gi7twPaJ0fktqH3tJk8sYVDukMxIr2wnt47/IqczHcDJm7PN/Oa/Xhvzoh
7Hw00If4/LmGB//H18luKq3MRnxWhZuE8KqeUcpPFDVLzm9AsWCLVV1Nh6hUcHdV
JPpvyddHPpSC3cmoJWzqhkv5r5phGZ97RO1pQEYM2nYEKoAeHrTCFqL8EWcXhnVY
SwRt0mTMwjuOAzd3hbsbqrEGRVBjz7I5r+1Wi/HhPxH8jdS2tBewsqeKCfq69kWb
4O0kB6118/Ae8bE4IviVSsqkgWVrRbFe0tlLkdd2f55GBbGZRVVO/Z26J6ZxU+Da
HbQIUCuhMSA/u0NDmXKr
=e0ly
-END PGP SIGNATURE-

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

Re: Tomcat issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kerapetse,

On 3/16/17 9:24 AM, Kerapetse Phorano wrote:
> Hello,
> 
> Please assist. We have tomcat 9.0.0.M18 
>  installed and
> running successfully on Ubuntu Server. We are experiencing an issue
> when we try to run tomcat manager from a different PC. We receive
> the following error message: HTTP Status 403 – Forbidden 
> --
> 
> *Type* Status Report
> 
> *Description* The server understood the request but refuses to
> authorize it.

Sounds like you haven't properly-configured authentication for the
manager application.

What have you done so far?

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

iQIcBAEBCAAGBQJYyrnTAAoJEBzwKT+lPKRY2hUP/RrYWu5eW7e+N0J3I2W6t/rp
jftgrQQMfccIYnk90MjClbFJllmXM535QNl+kgck1GGJy7vc+l/Bk0cCxTWEA3mk
QiUPESYDEdBBdSUzr5R1kqWc9UzhjxZ/jqGuJzH7WuWw9eWgZBy6CJmr9d16/sJz
3nBWHOtZa2waKAfmEuwOXfznTvkFHPrgOb571NrgmiPNUmaeBW7GzFYwSnvQfexx
UTtf+HO+pGsxTcrJ2zJ/DsfD+Ytqs/dRRMjkirrIMzxMpoSl4Nbq3SfN2myHs+Vi
V572OvCr+5BqvFjnZYcIDzvaT8iNGEvhEf+vfWFjdXRiZijqnJe2l3AdjHbNZiOj
RmlOe67gMWLi2WDNrAlbPslXsFAB3ntqaxah3Wm0lMdqFoLXoE1aoAPiw/v0KNZq
RZaZDi95abHv7GSEs/tIAUUe10q7Gne0FpI2eTOCIo/woawpv5l/beqUKxU6a5Bt
pr0rSoBmNem/mYxC/lPFfrpXF3mgLziN/ONrLFZHId46GavuxcfJDtBECa/BAXMR
ARtdhfjFZ8XJ0HvNEcmIe59rOCiYkzt5NPAvMzdhAPkMp9hPaKlV1KrlvjIuvsfr
Z1imtTcUvecsy/EvJxxXzlWYlKxiaCnvyHq1XYZKAOwfOMJsYEQARJrVdeQQMRWu
+fYeR/al2b+v4cOPydXY
=D7Id
-END PGP SIGNATURE-

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

Re: Tomcat 8.0.x series roadmap

[KK Gupta]

On Fri, Mar 10, 2017 at 11:35 AM, Mark Thomas  wrote:

> On 10/03/2017 16:21, KK Gupta wrote:
> > Hi All,
> >
> > Our product uses Tomcat 8.0.x series and we recently upgraded to tomcat
> > 8.0.41 in our product.
> >
> > http://tomcat.apache.org/whichversion.html shows that 8.0.41 as
> superseded.
> > So, I wanted to understand whether 8.0.x line is actively being
> maintained
> > or not?
>
> For now, yes but the expectation is users will move to 8.5.x sooner
> rather than later.
>
> > We are primarily concerned about security vulnerability fixes and need to
> > understand how long those would continue to be delivered on 8.0.x series.
>
> The initial plan was that these would have stopped already. The most
> likely scenario at the moment s that 8.0.x moves to a 3 to 6 monthly
> release cycle but that depends on there being a release manager to do
> the releases.
>
> Thank you for this information.


> > Moving to 8.5.x requires significant efforts from our side and thus
> trying
> > to understand pros and cons of remaining on 8.0.x line.
>
> Why so much work? 8.0.x to 8.5.x should be a fairly smooth upgrade. If
> there are problems it would help to know what they are.
>

Amit discussed it previously on this thread http://marc.info/?l=tomcat-
user=148703520014730=2

To summarize - we have a custom BIO based connector, where we ended up
extending few of the org.apache.tomcat.util.net and org.apache.coyote.http11
classes
with refactoring in 8.5.x those classes are gone.

For the longer term, we intend to change our architecture and get rid of
custom
connectors completely so that we do not end up in same situation again.
However that's proving to be a significant work.
Therefore, we were hoping that we could continue to use 8.0.x series


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

Re: CVEs Not Published

[Mark Thomas]

On 16/03/17 14:25, David Dillard wrote:
> Apologies if this is a duplicate, but I don't see this message in the
> archive so I'm resending.
> 
> 
> Hi,
> 
> I was recently reviewing Tomcat vulnerabilities and I noticed that it
> appears that several CVEs for Tomcat going back to at least September
> of last year have not been published by Mitre.  A few examples:
> 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6797 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8745
> 
> Does anyone know why they haven't been published?

At some point last year Mitre stopped populating their database from
information posted to bugtraq. Prior to that, population was sometimes
timely, sometime not.

There was no advance warning of this that I am aware of. I have a little
more insight now the ASF is a CNA but not much.

> And more
> importantly, does anyone know how to get these published?

The process has changed and now the projects need to submit this
themselves. See http://www.apache.org/security/committers.html step 15.f)

The ASF was provided with a list of CVEs that were issued in the time
between Mitre stopped populating their database from bugtraq and Mitre
informed the ASF of the new process (from memory this covers a period of
months). The ASF has provided the necessary data. When it is loaded is
up to Mitre.

Anyone can submit CVE information via the process indicated above.

> We use some tools to help us identify vulnerable versions based off
> of CVEs published in the NVD and not having them be published for so
> long is causing some problems.

You can try submitting them yourselves. Turnaround seems to be fairly
quick. At least CVE-2016-8747 is listed which I submitted a few days ago.

Mark

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

Tomcat issue

[Kerapetse Phorano]

Hello,

Please assist. We have tomcat 9.0.0.M18
 installed and running
successfully on Ubuntu Server.
We are experiencing an issue when we try to run tomcat manager from a
different PC.
We receive the following error message:
HTTP Status 403 – Forbidden
--

*Type* Status Report

*Description* The server understood the request but refuses to authorize it.


Regards,

Kerapetse

CVEs Not Published

[David Dillard]

Apologies if this is a duplicate, but I don't see this message in the archive 
so I'm resending.


Hi,

I was recently reviewing Tomcat vulnerabilities and I noticed that it appears 
that several CVEs for Tomcat going back to at least September of last year have 
not been published by Mitre.  A few examples:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6797
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8745

Does anyone know why they haven't been published?  And more importantly, does 
anyone know how to get these published?

We use some tools to help us identify vulnerable versions based off of CVEs 
published in the NVD and not having them be published for so long is causing 
some problems.


Regards,

David

Re: Syntax change in Set-Cookie header?

[Jim Griswold]

Thanks, Mark! I filed https://bz.apache.org/bugzilla/show_bug.cgi?id=60876.


Jim

On Thu, Mar 16, 2017 at 6:15 AM, Mark Thomas  wrote:

> On 15/03/17 21:56, Jim Griswold wrote:
> > Hi everyone,
> >
> > After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a
> syntax
> > change in the Set-Cookie header generated by Tomcat, and I was hoping to
> > confirm whether this is intentional or if I'm doing something
> incorrectly.
> >
> > The background:
> >
> > After upgrading Tomcat, some automated tests started failing. These tests
> > use an Apache CXF client to make requests to a service running inside
> > Tomcat, and then make various assertions on the value of the Set-Cookie
> > header returned from from the service.
> >
> > The root cause of the failure appears to be a change in the syntax used
> for
> > the Set-Cookie header which resulted in parsing failures in the client.
> >
> > The header that's generated by Tomcat 8.0.28 looks like:
> >
> > Set-Cookie: cookie_name=value; Path=/
> >
> > With 8.5.11, it looks like:
> >
> > Set-Cookie: cookie_name=value;path=/
> >
> > Note the missing space after the semicolon and the change from "Path" to
> > "path". After some digging around, I saw that the
> > new Rfc6265CookieProcessor was changed to be the default cookie
> processor.
> > When I followed instructions [1] to change back to the old processor, the
> > original behavior was restored and my tests pass again.
> >
> > Is this expected behavior? I see that RFC 6265 specifies [2] that there
> > must be a space between the semicolon and "path", and that it should be
> > "Path" with the first letter uppercased. Taking a look at the
> > Rfc6265CookieProcessor source code (the generateHeader method,
> > specifically), the lack of space and lower case p appear to be
> intentional,
> > yet don't seem to conform to the RFC the class is targeting.
> >
> > I am sure I must be missing something since this is the new default and
> > this is such a common behavior, but I've dug around for a while and can't
> > find another explanation.
>
> Those are implementation bugs. Please raise a Bugzilla issue. The case
> issue is probably wider than just path.
>
> Reading through the rest of the spec, they both look to be things
> clients should tolerate so you probably want to look at the client code
> as well.
>
> Kind regards,
>
> Mark
>
>
> >
> > Thanks in advance for your time and help!
> >
> > Jim
> >
> > [1]
> > http://stackoverflow.com/questions/38696081/how-to-
> change-cookie-processor-to-legacycookieprocessor-in-tomcat-8
> >
> > [2] https://tools.ietf.org/html/rfc6265#section-4.1.1
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: how do I know the exact commit for a particular version of tomcat?

[Konstantin Kolinko]

2017-03-16 16:45 GMT+03:00 Hoa Phan :
> I have been using the
> https://tomcat.apache.org/tomcat-8.0-doc/changelog.html
> and try to check out the revision with same message as latest change log of
> a particular version. Though it wasn't really get me the matching binary.
>
> Or can I find the commit hash in any file in the zip ?

You need to checkout the "tag" from subversion repository.  The tag
commit always differs a bit from preceding trunk revision, and is not
present in trunk.

E.g.
https://svn.apache.org/repos/asf/tomcat/tc8.0.x/tags/TOMCAT_8_0_37/

(The commit that creates the tag can be sees in the archives of dev@
mailing list, about 4 - 7 days before the release date).
E.g.
http://tomcat.markmail.org/thread/5pefzhttzce5xxhh

If you are using a Git mirror of Tomcat sources, svn tags are mapped
to Git branches.

Or just download a sources zip (tag.gz) file for a specific version
from archives.
http://tomcat.apache.org/download-80.cgi
-> "Archives" link


Best regards,
Konstantin Kolinko

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

how do I know the exact commit for a particular version of tomcat?

[Hoa Phan]

I have been using the
https://tomcat.apache.org/tomcat-8.0-doc/changelog.html
and try to check out the revision with same message as latest change log of
a particular version. Though it wasn't really get me the matching binary.

Or can I find the commit hash in any file in the zip ?

Thanks

Regards,

Hoa

Re: Syntax change in Set-Cookie header?

[Mark Thomas]

On 15/03/17 21:56, Jim Griswold wrote:
> Hi everyone,
> 
> After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a syntax
> change in the Set-Cookie header generated by Tomcat, and I was hoping to
> confirm whether this is intentional or if I'm doing something incorrectly.
> 
> The background:
> 
> After upgrading Tomcat, some automated tests started failing. These tests
> use an Apache CXF client to make requests to a service running inside
> Tomcat, and then make various assertions on the value of the Set-Cookie
> header returned from from the service.
> 
> The root cause of the failure appears to be a change in the syntax used for
> the Set-Cookie header which resulted in parsing failures in the client.
> 
> The header that's generated by Tomcat 8.0.28 looks like:
> 
> Set-Cookie: cookie_name=value; Path=/
> 
> With 8.5.11, it looks like:
> 
> Set-Cookie: cookie_name=value;path=/
> 
> Note the missing space after the semicolon and the change from "Path" to
> "path". After some digging around, I saw that the
> new Rfc6265CookieProcessor was changed to be the default cookie processor.
> When I followed instructions [1] to change back to the old processor, the
> original behavior was restored and my tests pass again.
> 
> Is this expected behavior? I see that RFC 6265 specifies [2] that there
> must be a space between the semicolon and "path", and that it should be
> "Path" with the first letter uppercased. Taking a look at the
> Rfc6265CookieProcessor source code (the generateHeader method,
> specifically), the lack of space and lower case p appear to be intentional,
> yet don't seem to conform to the RFC the class is targeting.
> 
> I am sure I must be missing something since this is the new default and
> this is such a common behavior, but I've dug around for a while and can't
> find another explanation.

Those are implementation bugs. Please raise a Bugzilla issue. The case
issue is probably wider than just path.

Reading through the rest of the spec, they both look to be things
clients should tolerate so you probably want to look at the client code
as well.

Kind regards,

Mark


> 
> Thanks in advance for your time and help!
> 
> Jim
> 
> [1]
> http://stackoverflow.com/questions/38696081/how-to-change-cookie-processor-to-legacycookieprocessor-in-tomcat-8
> 
> [2] https://tools.ietf.org/html/rfc6265#section-4.1.1
> 


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