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 <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 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 > >
