Mark / Rémy, Thanks again for your responses.
I'd like to point out one more thing. Mark stated: > 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. The problem I am experiencing is that applications are using a cookie value that contains a space. The cookie value was valid prior to Tomcat 8.5, but is no longer valid. This means that an update to Tomcat 8.5 prevents the previous cookies from being returned by HttpServletRequest.getCookies(). It also means that writing the cookie values is no longer valid. Writing the cookies could be adjusted, but reading the cookies cannot be fixed because the values are already written. Regards, Rob On Tue, Sep 6, 2016 at 5:13 PM, Rémy Maucherat <r...@apache.org> wrote: > 2016-09-06 23:04 GMT+02:00 Mark Thomas <ma...@apache.org>: > > > I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would > > be no change. 8.0.x uses the legacy parser by default so we are only > > talking about 8.5.x. here. > > > > The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for > > 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are > > trying to run the TCK, far more likely to cause problems than fix them. > > I don't see it as an option most (all?) real-world users would want to > > enable. It is the "Well, we don't recommend it but if you *really* want > > specification compliance then here you are." option. Which seems to be a > > good fit for this request. > > > > Well, yes, some items got added to the flag that are a bit questionable. I > see the very similar URI encoding, which defaults to UTF-8 if it's not > used. That's a similar behavior change that can hurt. > > Now it bundles too many "legacy HTTP" with some "extra Servlet spec > behaviors", and that's not the best combo. Ideally the "strict compliance" > flag should be limited to actual Servlet spec behaviors. > > > > And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one > > line in $CATALINA_BASE/conf/context.xml will switch the default back. > > > > Is the above enough to move you to a -0 on this? > > > > If people are ok with that new behavior, then that's what it can become. > > > > > > Thanks to > > > you actually, it looks doubtful anyone would have tackled a cookie > > > refactoring ... > > > > Thanks. I must confess that I do still have a small sense of dread any > > time a cookie related bug crops up. > > > > > People who need absolute compatibility can just as easily > > > configure another cookie support, but the requirement is really > > > illegitimate and counter productive. > > > > True. The same could be said for all the other defaults changed by > > STRICT_SERVLET_COMPLIANCE. > > > > > I also think the specification language is not intentional, it's only a > > > lack of update in the old javadoc basically. > > > > Indeed but unfortunately we are stuck with the spec language we have. If > > EG members could actually fix stuff like this directly rather than > > having to convince the Oracle spec lead to make the change... > > > > https://java.net/jira/browse/SERVLET_SPEC-37 > > > > I didn't pay a lot of attention to it then, and it doesn't seem to be > getting fixed. > > Rémy >
