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
