Mark,
On 4/24/26 6:04 AM, Mark Thomas wrote:
Hi all,
Prompted by some questions as $dayjob, I've been looking at how Tomcat
handles cookies attributes that are either present, or not present.
Currently, they are:
HttpOnly
Secure
Partitioned
HttpOnly and Secure have dedicated getters and setters on Cookie.
All can be set via Cookie.setAttribute(String, String) from 10.1.x onwards.
All current Tomcat versions have a Context attribute that sets HttpOnly
for all session cookies.
All Tomcat versions from 10.1.x onwards have a Context attribute that
sets Partitioned for all session cookies.
All Tomcat versions have a CookieProcessor attribute that sets
Partitioned for all cookies (including session cookies).
From 10.1.x, Cookie has an internal attribute map that holds the values
for all Cookie attributes.
12.0.x and 11.0.x use "" as the attribute value to indicate one of these
three attributes is set and only accepts "" to set them via
Cookie.setAttribute(String, String)
10.1.x uses "true" (case insensitive) as the attribute value to indicate
one of these three attributes is set and only accepts "true" (case
insensitive) to set them via Cookie.setAttribute(String, String)
The Servlet spec requires the use of "" for 6.1.x onwards (Tomcat 11.0.x
onwards) and "true" (case insensitive) for 10.1.x.
The purpose of the change from "true" (case insensitive) to "" was to
allow for future name only attributes without adding needing to add
special handling in either the specification or the container.
The switch from "true" (case insensitive) to "" is causing some issues
as there is no single version that works for all current Tomcat versions.
I don't want to add support for "true" (case insensitive) to 11.0.x
onwards as that just perpetuates the problem that switching to "" is
intended to solve.
My proposal to provide cross-version compatibility is as follows:
12.0.x - no change - use "" for any attribute that is either present or
not.
11.0.x - no change - use "" for any attribute that is either present or
not.
10.1.x - add special handling for the value of "" for these three
attributes and in that case store the value as "true".
... and this would include returning "" instead of "true"? Or does
storing "" end up storing "true"?
This is going to be awful for application developers, because they'll
have to check for these kinds of values if they care about their values.
At least the data type isn't Object and we also have to check for
Boolean.TRUE, Boolean.FALSE, and null. :/
9.0.x - no change - custom attributes not supported.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
