Hi, The main reason is RFC6265 is released after IE9, and IE9 is still in our supported browser list (though not recommended). I'm personally fine with using LegacyCookieProcessor instead of RFC6265CookieProcessor for LEGACY issues. However, it is not easy for an embedded Tomcat in an Spring-boot application to switch RFC6265CookieProcessor to LegacyCookieProcessor, unless we change the Spring-boot code. I am thinking of adding an system property, e.g. "org.apache.tomcat.util.http.CookieProcessor", to make the process easier.
------------------------------------------------------------------ From:Mark Thomas <ma...@apache.org> Time:2017 Jun 26 (Mon) 17:55 To:Tomcat Developers List <dev@tomcat.apache.org> Subject:Re: [VOTE] 8.0.x EOL - 30 June 2018 On 26/06/17 03:19, Huxing Zhang wrote: >> The only thing I can think of is lack of support for the BIO connectors. >> I have an easy fix for that if there is interest. Anything else? > > Also the RFC6265CookieProcessor. We've experienced several incompatibility > with LegacyCookieProcessor. > For example, cookies with leading dot is no longer valid in > RFC6265CookieProcessor. Since RFC6265 is clear that the leading '.' should not be there, I'm reluctant to introduce a change to allow it. Unsurprisingly, it is IE that needs the leading '.' in some cases. We have made exceptions for IE in the past. Do we want to do that here? LegacyCookieProcessor remains an option for those that need to support this particular quirk of IE. Personally, I'd prefer not to introduce a new option but I could be persuaded to support such a change if there was sufficient demand. Mark > ------------------------------------------------------------------ > From:Mark Thomas <ma...@apache.org> > Time:2017 Jun 24 (Sat) 23:26 > To:Tomcat Developers List <dev@tomcat.apache.org> > Subject:Re: [VOTE] 8.0.x EOL - 30 June 2018 > > > On 23/06/17 23:17, Emmanuel Bourg wrote: >> Le 23/06/2017 à 21:15, Christopher Schultz a écrit : >> >>> The idea was to encourage package repository maintainers to migrate to >>> Tomcat 8.5. If we never sundown Tomcat 8.0, they'll never move (witness >>> the presence of Tomcat 6.0 still lurking around half the Internet). >> >> As far as Debian is concerned, the migration to Tomcat 8.5 did happen in >> Debian 9. But Debian 8 users are stuck with Tomcat 8.0.x until June >> 2020. Tomcat 8.5 isn't a drop-in replacement for Tomcat 8.0 >> unfortunately, so it's a bit difficult to push this upgrade in a stable >> distribution. > > If 8.5.x was a drop-in replacement would that make a difference? > > And as a follow-up, what would need to change so 8.5.x was viewed a > drop-in replacement? > > The only thing I can think of is lack of support for the BIO connectors. > I have an easy fix for that if there is interest. Anything else? > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
