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 <ma...@apache.org> 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: > <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 > >
