I wasn't sure where to specifically raise this as this could be considered an undertow issue.

Changes to Undertow made in version [2.3.21.Final|Release v2.3.21.Final · undertow-io/undertow · GitHub] included in WildFly 39, specifically the RFC6265 changes, have resulted in new WildFly domains created with default parameters unable to have their cookies round tripped.

Out of the box, the undertow instanceid (eventually used as the cookie's jvm route) is derived from the domain server's jboss.node.name value which is of the form hostName:serverName. As the resulting cookie name contains a : character, the cookie value was wrapped in double quotes in previous versions. This isn't valid for RFC6265 based cookies.

In my fresh WildFly 39 domain, cookies are added to the response via [this line of code|undertow/core/src/main/java/io/undertow/server/Connectors.java at 2.3.22.Final · undertow-io/undertow · GitHub], this is because enableRfc6265Validation is not enabled for the domain's undertow subsystem out of the box. This results in cookies running through the LegacyCookieSupport class, specifically the [maybeQuote method|undertow/core/src/main/java/io/undertow/util/LegacyCookieSupport.java at 2.3.22.Final · undertow-io/undertow · GitHub] where, as the : character is present, the cookie value is surrounded by double quotes. Cookies here are created in the same way they were in previous versions.

The disconnect comes from the cookie parsing as they end up being parsed with 
rfc6265ParsingDisabled set to false. For the out of the box domain, this has run through [this method call|undertow/core/src/main/java/io/undertow/util/Cookies.java at 2.3.22.Final · undertow-io/undertow · GitHub]. The value of rfc6265ParsingDisabled is determined by a regex check to see if the cookie value [matches a specific pattern|undertow/core/src/main/java/io/undertow/util/Cookies.java at 2.3.22.Final · undertow-io/undertow · GitHub]. That's not the case here resulting in cookies created by undertow being unable to be validated by unedrtow with the exact same configuration.
 
Manually enabling the rfc6265-cookie-validation property on each HTTP/HTTPS listener in my domain's subsystem does allow the round trip to succeed.
 
The bottom line is that for out of the box domains, cookies are created without RFC6265 support but are parsed expecting RFC6265 compliant cookies.
 
I'm not sure why the cookie parser doesn't also use the undertow subsystem's rfc6265-cookie-validation property so that cookie parsing will always match cookie creation (which does use said property) rather than check a specific regex pattern to look for non RFC6265 cookies which clearly doesn't match all "legacy" cookies.
 
Perhaps this is an undertow issue to fix or WildFly should have  rfc6265-cookie-validation enabled by default now that that's the case for cookie validation. Or maybe this is something that's expected but undocumented.