On 06/09/2016 21:29, Rémy Maucherat wrote:
> 2016-09-06 19:11 GMT+02:00 Mark Thomas <ma...@apache.org>:
> 
>> 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.
>>
> I think I'm -1 for using the strict compliance flag for that. It's too big
> a behavior change, and the current situation is far more robust.

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.

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?

> 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

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to