tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be Servlet 3.1 compliant
Date Thu, 08 Sep 2016 15:00:44 GMT
Hash: SHA256


On 9/6/16 11:05 PM, Robert Winch wrote:
> 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.

It's an ugly hack, but you can always read the HTTP header yourself
and interpret the string as you see fit.

Or just use the LegacyCookieParser for a while, and re-write your
application's cookies to be more RFC-friendly.

- -chris

> On Tue, Sep 6, 2016 at 5:13 PM, Rémy Maucherat <>
> wrote:
>> 2016-09-06 23:04 GMT+02:00 Mark Thomas <>:
>>> 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
>>>> 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...
>>> I didn't pay a lot of attention to it then, and it doesn't seem
>>> to be
>> getting fixed.
>> Rémy
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message