Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant

2016-09-06 Thread Robert Winch
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

Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant

2016-09-06 Thread Robert Winch
6/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 >

Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant

2016-09-06 Thread Robert Winch
6, 2016 at 12:17 PM, Mark Thomas <ma...@apache.org> 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

Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant

2016-09-06 Thread Robert Winch
! Rob On Fri, Sep 2, 2016 at 4:46 PM, Rémy Maucherat <r...@apache.org> wrote: > 2016-09-02 23:19 GMT+02:00 Robert Winch <rwi...@gmail.com>: > > > I realize that I can manually configure LegacyCookieProcessor > > > > Yes, you'll have to configure the legacy co

Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant

2016-09-02 Thread Robert Winch
It appears that Tomcat 8.5.4 does not conform to the Servlet 3.1 specification in regards to the Cookie RFC that should be used. = Servlet 3.1 Specification Tomcat 8.5.4 states it follows the Servlet 3.1 specification [1]. The Servlet 3.1 Cookie class level Javadoc states [2]: > This class

WsSessionListener closes WebSocket Session on unprotected endpoint

2014-06-25 Thread Robert Winch
= Description I believe I may be experiencing a bug in Tomcat or simply misinterpreting JSR 356. Any thoughts on how to resolve the issue or if I a bug should be created would be welcome. To reproduce: 1) Authenticate to the application over HTTP. In my instance I am using Spring Security which

Re: VerifyError: ... Illegal constant pool index when jspx invokes a tagx on Tomcat 7.0.16

2011-12-08 Thread Robert Winch
On Thu, Dec 8, 2011 at 4:29 AM, Pid p...@pidster.com wrote: On 07/12/2011 17:32, Robert Winch wrote: 3) I have looked for any jars included in the war that might contain the wrong JspTag or PageContext. I tried to do an open type in Eclipse on both classes and found jsp-api and servlet

Re: VerifyError: ... Illegal constant pool index when jspx invokes a tagx on Tomcat 7.0.16

2011-12-08 Thread Robert Winch
On Thu, Dec 8, 2011 at 9:02 AM, Mark Thomas ma...@apache.org wrote: On 08/12/2011 14:19, Robert Winch wrote: On Thu, Dec 8, 2011 at 4:29 AM, Pid p...@pidster.com wrote: You say below that the compiled tags JSP don't appear to have been recompiled - either upgrade, or clear the work

VerifyError: ... Illegal constant pool index when jspx invokes a tagx on Tomcat 7.0.16

2011-12-07 Thread Robert Winch
We have a web application that was consistently getting a VerifyError whenever a jsp invoked a custom tagx. The jsp is a SiteMesh decorator that uses a custom tagx to display a Spring Security Authentication object. The issue was resolved by restarting the war using the Tomcat Manager, but I am