Re: Tomcat 8.5.4, Backup Manager and Serializable objects in httpSession
Hello, The exception was not swallowed. It was just in a different log file which I wasn't anticipating. Thanks, -Jared On Mon, May 29, 2017 at 4:03 PM, Jared Walker wrote: > Hello, > > I have a question about how BackupManager enforces or performs session > replication. > > I have added print outs to the serializing methods of an object I'm > binding to the http session. When I run a simple test (login to the > server, shut it down, then try to refresh) I do not stay logged in. > In looking through my debug output I have noticed the following on the > server that is acting as the backup for session replication: > > ClickSession:865 - Session read in: > ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= > ClickSession:867 - Login ID: 1 > 1249:ClickSession is bound to HttpSession tj8Zu6ANdJdftMJHPAOa/JyTBiY= > by key com.clickfind.http.ClickSession > > ClickSession:865 - Session read in: > ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= > ClickSession:867 - Login ID: 18201 > > ClickSession:865 - Session read in: > ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= > ClickSession:867 - Login ID: 18201 > > ClickSession:876 - Session write out: > ClickSession:877 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= > ClickSession:878 - Login ID: 1 > > As you can see, initially the session is replicated across with a > guest login (ID=1). Then there are subsequent messages that indicate > it is receiving updates to the session with an actual login value > (ID=18201). > > However, when it goes to replicate the session to another server > (because the primary node was shut down) you can see that it writes > out the original value for the session (ID=1). > > How can I ensure that the replication replaces the existing object in > the session attributes? > > Thanks, > -Jared - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4, Backup Manager and Serializable objects in httpSession
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jared, On 6/4/17 7:45 PM, Jared Walker wrote: > I was able to figure out that this issue was caused by a developer > adding logging code to the serialization that had a NPE. > Unfortunately the exception was not printed out to catalina.out so > it was very hard to find, but easy to fix. Was Tomcat swallowing the NPE? If so, please let me know where that happened. I've seen a few exception-swallowing pieces of Tomcat code, and I've been wanting to at least log those instances. - -chris > On Tue, May 30, 2017 at 10:30 AM, Christopher Schultz > wrote: Jared, > > On 5/29/17 5:03 PM, Jared Walker wrote: Hello, I have a question about how BackupManager enforces or performs session replication. I have added print outs to the serializing methods of an object I'm binding to the http session. When I run a simple test (login to the server, shut it down, then try to refresh) I do not stay logged in. In looking through my debug output I have noticed the following on the server that is acting as the backup for session replication: ClickSession:865 - Session read in: ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 1 1249:ClickSession is bound to HttpSession tj8Zu6ANdJdftMJHPAOa/JyTBiY= by key com.clickfind.http.ClickSession ClickSession:865 - Session read in: ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 ClickSession:865 - Session read in: ClickSession:866 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 ClickSession:876 - Session write out: ClickSession:877 - Session ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:878 - Login ID: 1 As you can see, initially the session is replicated across with a guest login (ID=1). Then there are subsequent messages that indicate it is receiving updates to the session with an actual login value (ID=18201). However, when it goes to replicate the session to another server (because the primary node was shut down) you can see that it writes out the original value for the session (ID=1). How can I ensure that the replication replaces the existing object in the session attributes? > > Can you post the code that generates the above output? > > Are all those messages printed on the backup node (only)? Give us > a little more information about the setup of your cluster. > > -chris >> >> - >> >> 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 > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZNXFaAAoJEBzwKT+lPKRYnQcP/AqCnHAMpWbi34hjXnxOxlSN Loq7fC7yLdOgD/KWtJgYLyh4Jz0rcdEo+fQcmTtVBNVcQBkXqWMVlVw4oOegtOYB 3Hg6CmmH5LxymUb9/HE82l9hhcSc5fdzZyVqEjaBNUsN06PEiuDgswWiOAHlnut7 X0kaokZwyO524oz3RhwLlC4iZA1bvBFpiyI9/xBM2Ur2NpgbEMXK8WSiE9LHQb92 QgmhZlUaZw4pONzBhv3vQluV2P/rCQkcqfgizZFRFmv//A51FjsxqbZ5qniU8B+v fUtNRIH2yMN43tM8US2NkwsqLOynsK6HXEg3581jK4zC79N8NOsOZKcNpOdbIU/t W7tkqtAmLa0KGz4/iWM0AIe6rQmrJ2iA3lnye8ZAL8n+gtnTW4BnePEBRYwpYzuQ pXEFJuAkH0skTHgYwVe0DQEN6pzj1EQUEnydAA8j0/9T7v4QVFswUF+9gbCBo1QG EoRckSZIRuj+QSV/6aNiJPXWpuAsr/DXho9rjBqkAch71Z0XUQXz7dnhrLipBc05 gek54XvFv0Z1o/cK4gqT/7fkJLlWjOV1WtObwzRY4w2vVlMNzsmlMxYRlUCJbW67 IXUOnH/fAYepxuqN3WwpL98vtzvSIDZHUTdeDABB5JVLmTVTc51QICTFSMY+6aQD dZI6oDm2jdz2j6D10OMx =z5QC -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.5.4, Backup Manager and Serializable objects in httpSession
Hello, I was able to figure out that this issue was caused by a developer adding logging code to the serialization that had a NPE. Unfortunately the exception was not printed out to catalina.out so it was very hard to find, but easy to fix. Thanks, -Jared On Tue, May 30, 2017 at 10:30 AM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jared, > > On 5/29/17 5:03 PM, Jared Walker wrote: >> Hello, >> >> I have a question about how BackupManager enforces or performs >> session replication. >> >> I have added print outs to the serializing methods of an object >> I'm binding to the http session. When I run a simple test (login >> to the server, shut it down, then try to refresh) I do not stay >> logged in. In looking through my debug output I have noticed the >> following on the server that is acting as the backup for session >> replication: >> >> ClickSession:865 - Session read in: ClickSession:866 - Session ID: >> tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 1 >> 1249:ClickSession is bound to HttpSession >> tj8Zu6ANdJdftMJHPAOa/JyTBiY= by key >> com.clickfind.http.ClickSession >> >> ClickSession:865 - Session read in: ClickSession:866 - Session ID: >> tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 >> >> ClickSession:865 - Session read in: ClickSession:866 - Session ID: >> tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 >> >> ClickSession:876 - Session write out: ClickSession:877 - Session >> ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:878 - Login ID: 1 >> >> As you can see, initially the session is replicated across with a >> guest login (ID=1). Then there are subsequent messages that >> indicate it is receiving updates to the session with an actual >> login value (ID=18201). >> >> However, when it goes to replicate the session to another server >> (because the primary node was shut down) you can see that it >> writes out the original value for the session (ID=1). >> >> How can I ensure that the replication replaces the existing object >> in the session attributes? > > Can you post the code that generates the above output? > > Are all those messages printed on the backup node (only)? Give us a > little more information about the setup of your cluster. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJZLZAqAAoJEBzwKT+lPKRYiaAP/2rf2SnGTDeSbGcQPGVUqiJW > RIOYQcFITI9NC7kimSJGzgpwOa0kC4QAB5VDMhm7Jxgk+f+JercgEWgauWb8gxGy > QV5UHDRdAv1oD5/17hS0tSnIVt7hq2+Ar181BGMV29JyLMCnvimOdyklMmGRV/ET > aS9V32ybE49oIZkdUU7bybYIR3hBn+1wPn2P+/8S0tw0CN1L4+LI7u/RZXAU4pua > U5gPUBz5N+T57txnEvd1yfGdLuZqoeWiS7VYOo2pRwtilYkYbzCh0SlDU5WPgbX/ > TFG3J2sukEilcz4k1MWxzRiiyjo1JuhhfqB2vx3QJsxDoceKK5yaquwbscieYIFN > ONJMez0v1REDJ5C5d0gK/KdgU2PuNRwwgNiW3AO/nMUawGwdVGAL1UySzBcBs6Yd > WCwoCrwG97mSw2XKP0ioCvVQeWARfZ9ZL2DXKjJDQoghlSzsJGk5jFz8+yJYELzR > EKWlHvStwxaqBxQhqC/3SptMUlH2BKLHwro9uWulh0n0Y0Ii9wDRC0B6HqIg99pI > Ghn0lUevGEV0k4UsEzfUoVCi9CWxhixYijx5ZMCM88jlek8dl/UF2Rp5ZC3+scoY > zsGU6u9qaiW6VQrCcvkDA2GURuXuRoELsz0YdnVglEIQ9fQhs2UTUhSu5WJdltSw > h2cgi4lJG+lJq+nInDbx > =VJNr > -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: Tomcat 8.5.4, Backup Manager and Serializable objects in httpSession
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jared, On 5/29/17 5:03 PM, Jared Walker wrote: > Hello, > > I have a question about how BackupManager enforces or performs > session replication. > > I have added print outs to the serializing methods of an object > I'm binding to the http session. When I run a simple test (login > to the server, shut it down, then try to refresh) I do not stay > logged in. In looking through my debug output I have noticed the > following on the server that is acting as the backup for session > replication: > > ClickSession:865 - Session read in: ClickSession:866 - Session ID: > tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 1 > 1249:ClickSession is bound to HttpSession > tj8Zu6ANdJdftMJHPAOa/JyTBiY= by key > com.clickfind.http.ClickSession > > ClickSession:865 - Session read in: ClickSession:866 - Session ID: > tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 > > ClickSession:865 - Session read in: ClickSession:866 - Session ID: > tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:867 - Login ID: 18201 > > ClickSession:876 - Session write out: ClickSession:877 - Session > ID: tj8Zu6ANdJdftMJHPAOa/JyTBiY= ClickSession:878 - Login ID: 1 > > As you can see, initially the session is replicated across with a > guest login (ID=1). Then there are subsequent messages that > indicate it is receiving updates to the session with an actual > login value (ID=18201). > > However, when it goes to replicate the session to another server > (because the primary node was shut down) you can see that it > writes out the original value for the session (ID=1). > > How can I ensure that the replication replaces the existing object > in the session attributes? Can you post the code that generates the above output? Are all those messages printed on the backup node (only)? Give us a little more information about the setup of your cluster. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZLZAqAAoJEBzwKT+lPKRYiaAP/2rf2SnGTDeSbGcQPGVUqiJW RIOYQcFITI9NC7kimSJGzgpwOa0kC4QAB5VDMhm7Jxgk+f+JercgEWgauWb8gxGy QV5UHDRdAv1oD5/17hS0tSnIVt7hq2+Ar181BGMV29JyLMCnvimOdyklMmGRV/ET aS9V32ybE49oIZkdUU7bybYIR3hBn+1wPn2P+/8S0tw0CN1L4+LI7u/RZXAU4pua U5gPUBz5N+T57txnEvd1yfGdLuZqoeWiS7VYOo2pRwtilYkYbzCh0SlDU5WPgbX/ TFG3J2sukEilcz4k1MWxzRiiyjo1JuhhfqB2vx3QJsxDoceKK5yaquwbscieYIFN ONJMez0v1REDJ5C5d0gK/KdgU2PuNRwwgNiW3AO/nMUawGwdVGAL1UySzBcBs6Yd WCwoCrwG97mSw2XKP0ioCvVQeWARfZ9ZL2DXKjJDQoghlSzsJGk5jFz8+yJYELzR EKWlHvStwxaqBxQhqC/3SptMUlH2BKLHwro9uWulh0n0Y0Ii9wDRC0B6HqIg99pI Ghn0lUevGEV0k4UsEzfUoVCi9CWxhixYijx5ZMCM88jlek8dl/UF2Rp5ZC3+scoY zsGU6u9qaiW6VQrCcvkDA2GURuXuRoELsz0YdnVglEIQ9fQhs2UTUhSu5WJdltSw h2cgi4lJG+lJq+nInDbx =VJNr -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.5.4 and LegacyCookieProcessor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jared, On 5/18/17 1:24 PM, Jared Walker wrote: > Now, I know this is only a work around as the "spec" being used by > this client is ancient. We are considering using the legacy parser > as a stop-gap measure until we can update the external clients with > a new version. Others have answered your core question, but I have another point to add: you can fix these clients by changing your application slightly. Modify your application to re-write your cookie values with a value that does not require any spec-ambiguous decoding. Specifically, use something like base64 encoding so your cookie value is always clean. If a client sends you a cookie value that is not in the "new" format, re-issue the cookie value to them with the new format. Issue all new cookies in the new format (of course). They it doesn't matter whether or not the clients are properly spec-compliant. > 2. The header for LegacyCookieProcesor.java explicitly states: > "This class is not thread-safe." That is a note to direct consumers of the class. Tomcat's use of this class is safe (it would be a pretty bad bug if it were not used in a safe way). - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkfBVkACgkQHPApP6U8 pFhLmw/9Eh04el3+EiDtpaO1gMwpfdo8E0FJ8eA0A0Jz03rgfQpCNRtvFJOAVcaw 8sg1g+WFYgi5fASv48fVk3p6Bccm7GRNTfXayYh/n9KCaW4nJdhnB9qVDSRubhps K/sLG7Jc4+x6tHmBa4V2c6/70whb89nWnmKBxXZ27pO6Bbn1Vd3bj2uVJCRyzS2/ MGlimUpyeXCYHcZMly7VoKJSEdyh8FWevuBZq2L16LvWs6ncVQxkfgNUm4TmxE5o ZvSxy0ThlBtJxYPi0evozVmaqBhzEE9mX/ARqR/qSU0jnka8M1MH2VjtFCLjCQ1A kj5NKqiNIVoyJypDpdk3DSoHZT29wpSULbem0pna/VsFZE9qEwT7FkPt30MpWAls qCcFAI+o+g3tV5Hv1dPGxnHmvH/iXmxC5HkYSlI4igaQ56eSOeFd4NKd3p7UPC1q mR+N+DqjJDDjSXTufebB33bdKbBOVjpq+fc67BQgqXP1fJFuK355lPUpNvmTCUY2 2xiC9cUSuqKx1h1RM3KwOmfDw/g4hUnyLYjabyhoLSr5tIPCIKeVwTTuMd6SvGaY SqDjsex397u5UxdXWj3aIbCPmQXHCB9tFPAk6eHLZpj9y7pDQoeLWhkzRG+slhzE M5vTS9xYM+xXB3Nvh2cswQQVs7F5KV+yiAVEhvJNnmTpLroiuhY= =EA0s -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.5.4 and LegacyCookieProcessor
On 18/05/2017 19:12, Caldarale, Charles R wrote: From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On Behalf Of Jared Walker Subject: Tomcat 8.5.4 and LegacyCookieProcessor We are migrating to the version of tomcat identified in the subject Before exposing an almost year-old version to the nasty real world, you might want to look at this: http://tomcat.apache.org/security-8.html and then pick a newer level (hint: 8.5.15 would be good). Plus that version includes a fix for the problem the OP is seeing: https://bz.apache.org/bugzilla/show_bug.cgi?id=60627 1. What are the security and compatibility concerns when using the legacy processor Sorry, can't answer that one. Security concerns - none known (if there were we'd have fixed them) Compatibility - tends to play better with older browsers. Lots of config options to handle various edge cases. Mark 2. The header for LegacyCookieProcesor.java explicitly states: "This class is not thread-safe." Can someone here with background knowledge explain exactly whats not thread-safe about the processor? Does this mean you cannot use it for multiple simultaneous requests (pretty hindering for a server) or does this mean that you cannot have multiple threads parse the cookie contents of a request in parallel (which isn't a very normal thing to do)? It's neither, really; there is one instance of CookieProcessor per , and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the is initialized. Were you to dynamically reset the fields while requests were in progress, you could get in trouble. The fields are described here: http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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: Tomcat 8.5.4 and LegacyCookieProcessor
> From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On > Behalf Of Jared Walker > Subject: Tomcat 8.5.4 and LegacyCookieProcessor > We are migrating to the version of tomcat identified in the subject Before exposing an almost year-old version to the nasty real world, you might want to look at this: http://tomcat.apache.org/security-8.html and then pick a newer level (hint: 8.5.15 would be good). > 1. What are the security and compatibility concerns when using the > legacy processor Sorry, can't answer that one. > 2. The header for LegacyCookieProcesor.java explicitly states: "This > class is not thread-safe." > Can someone here with background knowledge explain exactly whats not > thread-safe about the processor? Does this mean you cannot use it for > multiple simultaneous requests (pretty hindering for a server) or does > this mean that you cannot have multiple threads parse the cookie > contents of a request in parallel (which isn't a very normal thing to > do)? It's neither, really; there is one instance of CookieProcessor per , and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the is initialized. Were you to dynamically reset the fields while requests were in progress, you could get in trouble. The fields are described here: http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4
Thanks Mark, The issues was not there when i used 8.5.5.. Thank you for pointing me in that direction On Fri, Sep 16, 2016 at 5:20 PM, Mark Thomas wrote: > On 16/09/2016 07:44, Linux Support wrote: > > > > > I cannot make out where it picks up the alias tomcat > > https://bz.apache.org/bugzilla/show_bug.cgi?id=59910 > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 8.5.4
On 16/09/2016 07:44, Linux Support wrote: > I cannot make out where it picks up the alias tomcat https://bz.apache.org/bugzilla/show_bug.cgi?id=59910 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert, On 9/6/16 11:05 PM, Robert Winch wrote: > Mark / Rémy, > > Thanks again for your responses. > > I'd like to point out one more thing. Mark stated: > >> To date, the only problem we have seen with RFC6265 that comes to >> mind is that Tomcat rejects domain values with leading '.' when >> an application creates a cookie. > > The problem I am experiencing is that applications are using a > cookie value that contains a space. The cookie value was valid > prior to Tomcat 8.5, but is no longer valid. > > This means that an update to Tomcat 8.5 prevents the previous > cookies from being returned by HttpServletRequest.getCookies(). It > also means that writing the cookie values is no longer valid. > Writing the cookies could be adjusted, but reading the cookies > cannot be fixed because the values are already written. It's an ugly hack, but you can always read the HTTP header yourself and interpret the string as you see fit. Or just use the LegacyCookieParser for a while, and re-write your application's cookies to be more RFC-friendly. - -chris > On Tue, Sep 6, 2016 at 5:13 PM, Rémy Maucherat > wrote: > >> 2016-09-06 23:04 GMT+02:00 Mark Thomas : >> >>> I was assuming that Servlet 4.0 would update to RFC6265 so >>> 9.0.x would be no change. 8.0.x uses the legacy parser by >>> default so we are only talking about 8.5.x. here. >>> >>> The reason I was fine with adding this to >>> STRICT_SERVLET_COMPLIANCE for 8.5.x was that enabling >>> STRICT_SERVLET_COMPLIANCE is, unless you are trying to run the >>> TCK, far more likely to cause problems than fix them. I don't >>> see it as an option most (all?) real-world users would want to >>> enable. It is the "Well, we don't recommend it but if you >>> *really* want specification compliance then here you are." >>> option. Which seems to be a good fit for this request. >>> >> >> Well, yes, some items got added to the flag that are a bit >> questionable. I see the very similar URI encoding, which defaults >> to UTF-8 if it's not used. That's a similar behavior change that >> can hurt. >> >> Now it bundles too many "legacy HTTP" with some "extra Servlet >> spec behaviors", and that's not the best combo. Ideally the >> "strict compliance" flag should be limited to actual Servlet spec >> behaviors. >> >> >>> And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies >>> then one line in $CATALINA_BASE/conf/context.xml will switch >>> the default back. >>> >>> Is the above enough to move you to a -0 on this? >>> >> >> If people are ok with that new behavior, then that's what it can >> become. >> >>> Thanks to you actually, it looks doubtful anyone would have tackled a cookie refactoring ... >>> >>> Thanks. I must confess that I do still have a small sense of >>> dread any time a cookie related bug crops up. >>> People who need absolute compatibility can just as easily configure another cookie support, but the requirement is really illegitimate and counter productive. >>> >>> True. The same could be said for all the other defaults changed >>> by STRICT_SERVLET_COMPLIANCE. >>> I also think the specification language is not intentional, it's only a lack of update in the old javadoc basically. >>> >>> Indeed but unfortunately we are stuck with the spec language we >>> have. If EG members could actually fix stuff like this directly >>> rather than having to convince the Oracle spec lead to make the >>> change... >>> >>> https://java.net/jira/browse/SERVLET_SPEC-37 >>> >>> I didn't pay a lot of attention to it then, and it doesn't seem >>> to be >> getting fixed. >> >> Rémy >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJX0X0cAAoJEBzwKT+lPKRYvDwP/iX4ZuCtJXxDRm+cYG9Ot3jg tKnnrIe8FHnHB8pzRKNWnVsb2CFn/FaqOPqeHZ8+nlE38sM7zKzTZJoo3PKBz7eZ dD4BvHMP0p2dobXmn8bUOtfRc9xxXQ1xC3SmdXQeEynmKkXzfAq9OO+f8a4unlT1 gSEqTBddnPnwWMm+OsKm7tgAfn6O2D4bVvDNC+GRHH7+CSfBF+dxvR6qmRqz9B26 vA2Q/qXEv0VHWKP0+fu5X91x18gqDzXWBluR6zATVwZUa23WjGHwxIKGQ/rne1GE 15Yp5ucghV9ip8IoAthMq7DLcby5WIwGLvTGtN06cemD1U6wXbhWwdRxri+AP6T1 GOQM+aL7VIZD2KFr5rMSXHuPHBSvjaFfodhSALnh9tJtt33PGJ/eiSpYKJA5lKw3 8PV/Z+2kJlpuXmQwJ82OiQLfUgjCrEhibUFxiXphrJ/KOhIoBC7fWFih9OLoD+4S jGS7vT/uLZGmF59t3sL6Wu2C/Ew4tgaeeUazrVaHyjqiVftiBAeMR6el844l64Tj Wh2lXtfnpDskWoRbkseem+tiMK7j431vfialh6EbhPxCaLZUo50zHdD9X2Tw009A PdQH3mUT79Fwj8CREwOLYVH3UeGg414e+UdImQVKnl0Epc8fpQqi0G3+QOXKD+p7 /p12dXhJu1Z2zefdMirx =b14o -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.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
Mark / Rémy, Thanks again for your responses. I'd like to point out one more thing. Mark stated: > To date, the only problem we have seen with RFC6265 that comes to mind > is that Tomcat rejects domain values with leading '.' when an > application creates a cookie. The problem I am experiencing is that applications are using a cookie value that contains a space. The cookie value was valid prior to Tomcat 8.5, but is no longer valid. This means that an update to Tomcat 8.5 prevents the previous cookies from being returned by HttpServletRequest.getCookies(). It also means that writing the cookie values is no longer valid. Writing the cookies could be adjusted, but reading the cookies cannot be fixed because the values are already written. Regards, Rob On Tue, Sep 6, 2016 at 5:13 PM, Rémy Maucherat wrote: > 2016-09-06 23:04 GMT+02:00 Mark Thomas : > > > I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would > > be no change. 8.0.x uses the legacy parser by default so we are only > > talking about 8.5.x. here. > > > > The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for > > 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are > > trying to run the TCK, far more likely to cause problems than fix them. > > I don't see it as an option most (all?) real-world users would want to > > enable. It is the "Well, we don't recommend it but if you *really* want > > specification compliance then here you are." option. Which seems to be a > > good fit for this request. > > > > Well, yes, some items got added to the flag that are a bit questionable. I > see the very similar URI encoding, which defaults to UTF-8 if it's not > used. That's a similar behavior change that can hurt. > > Now it bundles too many "legacy HTTP" with some "extra Servlet spec > behaviors", and that's not the best combo. Ideally the "strict compliance" > flag should be limited to actual Servlet spec behaviors. > > > > And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one > > line in $CATALINA_BASE/conf/context.xml will switch the default back. > > > > Is the above enough to move you to a -0 on this? > > > > If people are ok with that new behavior, then that's what it can become. > > > > > > Thanks to > > > you actually, it looks doubtful anyone would have tackled a cookie > > > refactoring ... > > > > Thanks. I must confess that I do still have a small sense of dread any > > time a cookie related bug crops up. > > > > > People who need absolute compatibility can just as easily > > > configure another cookie support, but the requirement is really > > > illegitimate and counter productive. > > > > True. The same could be said for all the other defaults changed by > > STRICT_SERVLET_COMPLIANCE. > > > > > I also think the specification language is not intentional, it's only a > > > lack of update in the old javadoc basically. > > > > Indeed but unfortunately we are stuck with the spec language we have. If > > EG members could actually fix stuff like this directly rather than > > having to convince the Oracle spec lead to make the change... > > > > https://java.net/jira/browse/SERVLET_SPEC-37 > > > > I didn't pay a lot of attention to it then, and it doesn't seem to be > getting fixed. > > Rémy >
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
2016-09-06 23:04 GMT+02:00 Mark Thomas : > I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would > be no change. 8.0.x uses the legacy parser by default so we are only > talking about 8.5.x. here. > > The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for > 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are > trying to run the TCK, far more likely to cause problems than fix them. > I don't see it as an option most (all?) real-world users would want to > enable. It is the "Well, we don't recommend it but if you *really* want > specification compliance then here you are." option. Which seems to be a > good fit for this request. > Well, yes, some items got added to the flag that are a bit questionable. I see the very similar URI encoding, which defaults to UTF-8 if it's not used. That's a similar behavior change that can hurt. Now it bundles too many "legacy HTTP" with some "extra Servlet spec behaviors", and that's not the best combo. Ideally the "strict compliance" flag should be limited to actual Servlet spec behaviors. > And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one > line in $CATALINA_BASE/conf/context.xml will switch the default back. > > Is the above enough to move you to a -0 on this? > If people are ok with that new behavior, then that's what it can become. > > > Thanks to > > you actually, it looks doubtful anyone would have tackled a cookie > > refactoring ... > > Thanks. I must confess that I do still have a small sense of dread any > time a cookie related bug crops up. > > > People who need absolute compatibility can just as easily > > configure another cookie support, but the requirement is really > > illegitimate and counter productive. > > True. The same could be said for all the other defaults changed by > STRICT_SERVLET_COMPLIANCE. > > > I also think the specification language is not intentional, it's only a > > lack of update in the old javadoc basically. > > Indeed but unfortunately we are stuck with the spec language we have. If > EG members could actually fix stuff like this directly rather than > having to convince the Oracle spec lead to make the change... > > https://java.net/jira/browse/SERVLET_SPEC-37 > > I didn't pay a lot of attention to it then, and it doesn't seem to be getting fixed. Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
On 06/09/2016 21:29, Rémy Maucherat wrote: > 2016-09-06 19:11 GMT+02:00 Mark Thomas : > >> This looks like something that is a good fit for >> STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change >> the default CookieProcessor to LegacyCookieProcessor. >> > I think I'm -1 for using the strict compliance flag for that. It's too big > a behavior change, and the current situation is far more robust. I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would be no change. 8.0.x uses the legacy parser by default so we are only talking about 8.5.x. here. The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are trying to run the TCK, far more likely to cause problems than fix them. I don't see it as an option most (all?) real-world users would want to enable. It is the "Well, we don't recommend it but if you *really* want specification compliance then here you are." option. Which seems to be a good fit for this request. And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one line in $CATALINA_BASE/conf/context.xml will switch the default back. Is the above enough to move you to a -0 on this? > Thanks to > you actually, it looks doubtful anyone would have tackled a cookie > refactoring ... Thanks. I must confess that I do still have a small sense of dread any time a cookie related bug crops up. > People who need absolute compatibility can just as easily > configure another cookie support, but the requirement is really > illegitimate and counter productive. True. The same could be said for all the other defaults changed by STRICT_SERVLET_COMPLIANCE. > I also think the specification language is not intentional, it's only a > lack of update in the old javadoc basically. Indeed but unfortunately we are stuck with the spec language we have. If EG members could actually fix stuff like this directly rather than having to convince the Oracle spec lead to make the change... https://java.net/jira/browse/SERVLET_SPEC-37 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
On 06/09/2016 20:57, Robert Winch wrote: > Mark, > > Thanks again for your detailed response. > > In addition to the STRICT_SERVLET_COMPLIANCE flag, would you consider > supporting the older RFC if a cookie version was explicitly set on the > Cookie? If applications want to explicitly send version 1 cookies then they'll need to configure the LegacyCookieProcessor. Given that RFC6265 essentially documents the current browser behaviour and also that RFC6265 says clients should ignore the version attribute I'd be surprised if any but a tiny minority of applications actually needed to send the version attribute. I guess if someone has written a custom client that actually implements RFC2109 they'd need this but it is going to be that unusual. Mark > > Cheers, > Rob > > On Tue, Sep 6, 2016 at 1:21 PM, Mark Thomas wrote: > >> On 06/09/2016 19:02, Robert Winch wrote: >>> Mark, >>> >>> Thank you for the detailed response. >>> >>> I'm looking to assess the full impact of applications that might choose >> to >>> use LegacyCookieProcessor. Can you elaborate on why using >>> LegacyCookieProcessor is a bad idea? >> >> It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the >> current reality as well as the RFC6265 processor. >> >> As an aside, the Servlet spec implies strict adherence to RFC2109. That >> would be fairly messy. From memory, it breaks interoperability with >> Google and IE, as well as a bunch of other issues. >> >> Rfc6262CookieProcessor is better because: >> - it is a much closer match to how browsers actually behave >> - it handles UTF-8 (this is actually a deviation from RFC6265) >> >> To quote from the intro of RFC6265: >> >> Prior to this document, there were at least three descriptions of >> cookies: the so-called "Netscape cookie specification" [Netscape], >> RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these >> documents describe how the Cookie and Set-Cookie headers are actually >> used on the Internet (see [Kri2001] for historical context). >> >> >> The potential downside is that Tomcat is strict in what it allows >> applications to send. If applications don't adhere to RFC6265 then they >> will see exceptions around cookie handling. >> >>> Are you aware of other containers that also use RFC6265? >> >> I haven't undertaken any sort of survey. >> >> To date, the only problem we have seen with RFC6265 that comes to mind >> is that Tomcat rejects domain values with leading '.' when an >> application creates a cookie. We could be lenient here but that goes >> against our general philosophy of not adding workarounds for bad >> application behaviour expect in exception circumstances (and this isn't >> close to this point so far). >> >> Mark >> >> >> - >> 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: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
2016-09-06 19:11 GMT+02:00 Mark Thomas : > This looks like something that is a good fit for > STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change > the default CookieProcessor to LegacyCookieProcessor. > > I think I'm -1 for using the strict compliance flag for that. It's too big a behavior change, and the current situation is far more robust. Thanks to you actually, it looks doubtful anyone would have tackled a cookie refactoring ... People who need absolute compatibility can just as easily configure another cookie support, but the requirement is really illegitimate and counter productive. I also think the specification language is not intentional, it's only a lack of update in the old javadoc basically. Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
Mark, Thanks again for your detailed response. In addition to the STRICT_SERVLET_COMPLIANCE flag, would you consider supporting the older RFC if a cookie version was explicitly set on the Cookie? Cheers, Rob On Tue, Sep 6, 2016 at 1:21 PM, Mark Thomas wrote: > On 06/09/2016 19:02, Robert Winch wrote: > > Mark, > > > > Thank you for the detailed response. > > > > I'm looking to assess the full impact of applications that might choose > to > > use LegacyCookieProcessor. Can you elaborate on why using > > LegacyCookieProcessor is a bad idea? > > It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the > current reality as well as the RFC6265 processor. > > As an aside, the Servlet spec implies strict adherence to RFC2109. That > would be fairly messy. From memory, it breaks interoperability with > Google and IE, as well as a bunch of other issues. > > Rfc6262CookieProcessor is better because: > - it is a much closer match to how browsers actually behave > - it handles UTF-8 (this is actually a deviation from RFC6265) > > To quote from the intro of RFC6265: > > Prior to this document, there were at least three descriptions of > cookies: the so-called "Netscape cookie specification" [Netscape], > RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these > documents describe how the Cookie and Set-Cookie headers are actually > used on the Internet (see [Kri2001] for historical context). > > > The potential downside is that Tomcat is strict in what it allows > applications to send. If applications don't adhere to RFC6265 then they > will see exceptions around cookie handling. > > > Are you aware of other containers that also use RFC6265? > > I haven't undertaken any sort of survey. > > To date, the only problem we have seen with RFC6265 that comes to mind > is that Tomcat rejects domain values with leading '.' when an > application creates a cookie. We could be lenient here but that goes > against our general philosophy of not adding workarounds for bad > application behaviour expect in exception circumstances (and this isn't > close to this point so far). > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
On 06/09/2016 19:02, Robert Winch wrote: > Mark, > > Thank you for the detailed response. > > I'm looking to assess the full impact of applications that might choose to > use LegacyCookieProcessor. Can you elaborate on why using > LegacyCookieProcessor is a bad idea? It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the current reality as well as the RFC6265 processor. As an aside, the Servlet spec implies strict adherence to RFC2109. That would be fairly messy. From memory, it breaks interoperability with Google and IE, as well as a bunch of other issues. Rfc6262CookieProcessor is better because: - it is a much closer match to how browsers actually behave - it handles UTF-8 (this is actually a deviation from RFC6265) To quote from the intro of RFC6265: Prior to this document, there were at least three descriptions of cookies: the so-called "Netscape cookie specification" [Netscape], RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these documents describe how the Cookie and Set-Cookie headers are actually used on the Internet (see [Kri2001] for historical context). The potential downside is that Tomcat is strict in what it allows applications to send. If applications don't adhere to RFC6265 then they will see exceptions around cookie handling. > Are you aware of other containers that also use RFC6265? I haven't undertaken any sort of survey. To date, the only problem we have seen with RFC6265 that comes to mind is that Tomcat rejects domain values with leading '.' when an application creates a cookie. We could be lenient here but that goes against our general philosophy of not adding workarounds for bad application behaviour expect in exception circumstances (and this isn't close to this point so far). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
Mark, Thank you for the detailed response. I'm looking to assess the full impact of applications that might choose to use LegacyCookieProcessor. Can you elaborate on why using LegacyCookieProcessor is a bad idea? Are you aware of other containers that also use RFC6265? Thanks, Rob On Tue, Sep 6, 2016 at 12:17 PM, Mark Thomas wrote: > On 06/09/2016 18:11, Mark Thomas wrote: > > On 06/09/2016 17:38, Robert Winch wrote: > >> Thank you for your response. > >> > >> I don't see how the Tomcat documentation can be fixed unless the > Tomcat's > >> Servlet APIs are going to deviate from the Servlet 3.1 specification. If > >> Tomcat continues to deviate from the specification, I don't see how > Tomcat > >> 8.5 can claim Servlet 3.1 compliance. > > > > There are numerous places where Tomcat deviates from the the Servlet > > spec by default for various reasons including, amongst others, > > performance, standard practise and plain common sense. > > > > Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you > > really want to stick to the letter of the Servlet spec. Back when we > > had access to a current TCK, it was required to be set to pass the TCK. > > > >> Do you see a way to get the Tomcat cookie implementation to align with > the > >> Servlet 3.1 API specification? Can you elaborate on why Tomcat has > decided > >> to deviate from the specification in this respect? Is there a reason we > >> cannot fix the behavior (especially if the cookie version is explicitly > >> set)? > > > > This looks like something that is a good fit for > > STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change > > the default CookieProcessor to LegacyCookieProcessor. > > > > As to why the default is RFC6265, neither browsers nor servers > > implemented them fully and/or correctly. > > Them being the previous cookie specs. > > > Tomcat discovered this the hard > > way several years ago when we tightened up the cookie parsing code to > > follow the specs as a result of some security issues. The majority of > > apps promptly broke. > > > > Mark > > > > > > - > > 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: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
On 06/09/2016 18:11, Mark Thomas wrote: > On 06/09/2016 17:38, Robert Winch wrote: >> Thank you for your response. >> >> I don't see how the Tomcat documentation can be fixed unless the Tomcat's >> Servlet APIs are going to deviate from the Servlet 3.1 specification. If >> Tomcat continues to deviate from the specification, I don't see how Tomcat >> 8.5 can claim Servlet 3.1 compliance. > > There are numerous places where Tomcat deviates from the the Servlet > spec by default for various reasons including, amongst others, > performance, standard practise and plain common sense. > > Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you > really want to stick to the letter of the Servlet spec. Back when we > had access to a current TCK, it was required to be set to pass the TCK. > >> Do you see a way to get the Tomcat cookie implementation to align with the >> Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided >> to deviate from the specification in this respect? Is there a reason we >> cannot fix the behavior (especially if the cookie version is explicitly >> set)? > > This looks like something that is a good fit for > STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change > the default CookieProcessor to LegacyCookieProcessor. > > As to why the default is RFC6265, neither browsers nor servers > implemented them fully and/or correctly. Them being the previous cookie specs. > Tomcat discovered this the hard > way several years ago when we tightened up the cookie parsing code to > follow the specs as a result of some security issues. The majority of > apps promptly broke. > > Mark > > > - > 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: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
On 06/09/2016 17:38, Robert Winch wrote: > Thank you for your response. > > I don't see how the Tomcat documentation can be fixed unless the Tomcat's > Servlet APIs are going to deviate from the Servlet 3.1 specification. If > Tomcat continues to deviate from the specification, I don't see how Tomcat > 8.5 can claim Servlet 3.1 compliance. There are numerous places where Tomcat deviates from the the Servlet spec by default for various reasons including, amongst others, performance, standard practise and plain common sense. Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you really want to stick to the letter of the Servlet spec. Back when we had access to a current TCK, it was required to be set to pass the TCK. > Do you see a way to get the Tomcat cookie implementation to align with the > Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided > to deviate from the specification in this respect? Is there a reason we > cannot fix the behavior (especially if the cookie version is explicitly > set)? This looks like something that is a good fit for STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change the default CookieProcessor to LegacyCookieProcessor. As to why the default is RFC6265, neither browsers nor servers implemented them fully and/or correctly. Tomcat discovered this the hard way several years ago when we tightened up the cookie parsing code to follow the specs as a result of some security issues. The majority of apps promptly broke. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
2016-09-06 18:38 GMT+02:00 Robert Winch : > Thank you for your response. > You're welcome. Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
Thank you for your response. I don't see how the Tomcat documentation can be fixed unless the Tomcat's Servlet APIs are going to deviate from the Servlet 3.1 specification. If Tomcat continues to deviate from the specification, I don't see how Tomcat 8.5 can claim Servlet 3.1 compliance. Do you see a way to get the Tomcat cookie implementation to align with the Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided to deviate from the specification in this respect? Is there a reason we cannot fix the behavior (especially if the cookie version is explicitly set)? Thanks! Rob On Fri, Sep 2, 2016 at 4:46 PM, Rémy Maucherat wrote: > 2016-09-02 23:19 GMT+02:00 Robert Winch : > > > I realize that I can manually configure LegacyCookieProcessor > > > > Yes, you'll have to configure the legacy cookie processor to support the > less formal former cookie RFCs, this is as expected. If you find any > discrepancies about that in the Tomcat documentation, you may file a bug. > The default will remain to use the current cookie RFC. > > Rémy >
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
2016-09-02 23:19 GMT+02:00 Robert Winch : > I realize that I can manually configure LegacyCookieProcessor > > Yes, you'll have to configure the legacy cookie processor to support the less formal former cookie RFCs, this is as expected. If you find any discrepancies about that in the Tomcat documentation, you may file a bug. The default will remain to use the current cookie RFC. Rémy
Re: Tomcat 8.5.4 making sessions when used with NIO connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Swati, On 8/11/16 2:16 AM, swati jain wrote: > Tomcat Version - 8.5.4 ( Embedded) Platform - Linux > > When NIO connector is used with Embedded Tomcat, it creates a > session per request. The session lasts for 30 minutes. Is there a > way to configure connector in such a way that no session is > created. The connectors don't create sessions, so this is unlikely to do with the choice of connector. What happens if you try the APR or NIO2 connectors and repeat your tests? > I have traffic of around 4 requests per second. All the > requests are state less. so each of them create a session. After 10 > minutes, the Tomcat stops taking any further requests and when I > viewed the heap dump, it says there is a concurrent map which has > many objects of sessions. Are you able to instrument the server at all, or observe this in a test environment? It's easy to attach a HttpServletListener and dump stack traces to reveal the places where the sessions are being created. > While using Tomcat 6.0.36,. no sessions were created per request. > After migration to Tomcat 8.5.4, this problem has started. What components are involved, here? Specifically, are you using JSP or anything that is known for surprisingly-creating sessions? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXrMg9AAoJEBzwKT+lPKRYoOQP/0r375Pd1V03tgC3SKPbV6fD WT2alGFvED5TveICl8DTxgtRDeEg/iLXAf5ewRM7r6/9VKKsuSYC7Bs45NCr2KC0 it+u35GH4DQCH7BfjeVlkeqqdW5JwCFzSF6NoPtedmbYrUMA60eVwDSes56U4XUj x2ge26STfkG6rd0iVHkmjzJ7Ot/LEctOA4FVubIM3YYV+ERDByuE08GTODEcqNLT fJSkloJ1/Gjc3QuK5TAQ8tOz1CROE1NIXkXQzKU1wr7DqZzJBkUQNbcvp8mE56Ej +b+Eby71P7Fri9ah9LveKtHUshl7sFrJoDp3x/O/1aJ8MvbG5jMoja1HdIRgds6E +TjZnCipI1iSFhPFwOpNjiBbzEA1pDuFzIMmrmqSwTayQbXvhHa9mYqGjb+x9IT+ ftpXib5gzKRcvCeZZDIdGU5nmqp7yBCSAPtWcYVnIocsvYxsLDu8LQWUPs8M7cP0 /9x5IN5ADQBkzFHw4P2ebo0sR8i9d8CLrcPGS3ZDK0Y/mBWujmqhrKT8xfE47CeR 5CBhEyi3I1e2DK6w4XwP75LgaBmPbzjj6urmuW5mGF6kEAyI/o5S/qOOTl61dpBD YQl9W7rg7E76Uzw6VprjdcM73OgSHpm0UoiI93mJUco79oWyma70hnYzrP+A6ZfB VZkDJP7lx6S/Bp5TPBV1 =Tw6q -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.5.4 and Log4j2
From: Mark Thomas Sent: Thursday, July 28, 2016 15:32 To: Tomcat Users List Subject: Re: Tomcat 8.5.4 and Log4j2 On 28/07/2016 20:09, Chen Levy wrote: > Hello all > > I’ve been using Tomcat 8.0.X with Log4j2, both for Tomcat logging and for my > applicative logs, for a long time now. > It was done using the following jars: > extras/tomcat-juli.jar > extras/tomcat-juli-adapters.jar jars > > I’m in the process of upgrading to Tomcat 8.5.4 and according to > https://bz.apache.org/bugzilla/show_bug.cgi?id=58588 these jars are no longer > distributed. > > I followed the instructions in > http://logging.apache.org/log4j/2.0/log4j-jul/index.html and performed the > following: > 1. Added -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager > to the java command > 2. Added log4j-jul-2.6.2.jar to the classpath > > Other than adding these through setenv.bat, I did not modify anything with > the distribution (apache-tomcat-8.5.4-windows-x64.zip) > > Now, when invoking startup.bat, Tomcat starts and exits immediately, without > any console or log output use: catalina.bat run to start and report the error message. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks for the hint Mark There was a ClassNotFoundException where log4j-juli required log4j-api in the classpath, then log4-core and finally disruptor.jar So I moved these jars from Tomcat’s /lib folder, where I used to place them in v8.0, to /bin folder, next to tomcat-juli.jar; and added them all to the classpath. I’m no sure if that is the right way, but it’s working. I’m pasting the content of my setenv.bat for those who may encounter this issue in the future (I’m using a setenv.sh file as well if anyone is interested): rem Set the classpath for Log4j2 set "CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\log4j-jul-2.6.2.jar;%CATALINA_HOME%\bin\log4j-api-2.6.2.jar;%CATALINA_HOME%\bin\log4j-core-2.6.2.jar;%CATALINA_HOME%\bin\disruptor-3.3.4.jar" rem Log4j2 configuration set CATALINA_OPTS=%CATALINA_OPTS% -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Dlog4j.configurationFile=file://%CATALINA_HOME%\conf\log4j2.xml Please let me know if there’s another, better way to do it Thanks Chen
Re: Tomcat 8.5.4 and Log4j2
On 28/07/2016 20:09, Chen Levy wrote: > Hello all > > I’ve been using Tomcat 8.0.X with Log4j2, both for Tomcat logging and for my > applicative logs, for a long time now. > It was done using the following jars: > extras/tomcat-juli.jar > extras/tomcat-juli-adapters.jar jars > > I’m in the process of upgrading to Tomcat 8.5.4 and according to > https://bz.apache.org/bugzilla/show_bug.cgi?id=58588 these jars are no longer > distributed. > > I followed the instructions in > http://logging.apache.org/log4j/2.0/log4j-jul/index.html and performed the > following: > 1. Added -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager > to the java command > 2. Added log4j-jul-2.6.2.jar to the classpath > > Other than adding these through setenv.bat, I did not modify anything with > the distribution (apache-tomcat-8.5.4-windows-x64.zip) > > Now, when invoking startup.bat, Tomcat starts and exits immediately, without > any console or log output use: catalina.bat run to start and report the error message. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
