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: <quote> 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). </quote> 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
