In our implementation, we initialize the application space with <cfapplication... setClientCookies="no"> and then use CFCookie to send the CFID and CFToken cookies so we can control the attributes. The cookies we set get the names CFID and CFTOKEN (all-upper-case).
If a user with no cookies goes to the Lucee administrator before they hit our application, Lucee generates 'cfid' and 'cftoken' cookies (all-lower-case names). If the user then browses to our application, additional CFID and CFTOKEN cookies are added. This duplication interfere with our sessions. The only work-around we've found is to manually clear the lower-case variants using the browser's debug tools
If the CFID and CFTOKEN cookies are created first, Lucee does not create the redundant cookies
Linux (CentOS 7), Java 8 and Java 11
Since your CFML code is the one creating the duplicate cookies, wouldn't the onus be upon you to check for their existence prior to re-creating them? And to delete if necessary existing cookies with the wrong case.
we’ve tried that - but the case differences make things very tricky. The only way to know that the cookies are defined as lower-case is to parse out the raw cookies from CGI. We’ve done that, but haven’t had any luck deleting ‘cfid’ and adding ‘CFID’ in the same response
This is also related to
The multiple/duplicate cookie setting isn’t a problem as long as the client overwrites the first instance with the second - but not all clients are case-insensitive with their cookie name handling. If Lucee’s internal cookie names for CFID/CFTOKEN were updated to all-upper-case so the names were exactly the same as the cookie names produced by CFCookie… the conflict would be resolved for most cases (again, except for clients that get confused by duplicate set-cookie headers)
I've checked this ticket and confirmed the issue happened on lucee latest version 22.214.171.124-SNAPSHOT also. This issue was already confirmed in LDEV-2466. Yes In lucee create new cookies with case-sensitive instead of overwriting the cookie.