With every legacy project there comes a time, when some dependencies need to be updated, code needs to cleaned and with Legacy Java projects the truth is much the same. But when upgrading Projects and following Migration guides there can be cases where not all the seemingly important things get mentioned. In this case the Jetty 9 to 10 upgrade came with a lot more surprises than expected.

Jetty 9 and its earlier versions were more relaxed about following conventions and standards, giving developers more freedom to do what they wanted.

One example is that older Jetty 9 versions loosely followed the rfc2965 standard and didn’t enforce many of its requirements. IIn our project, this meant that JSON objects were considered valid cookie values. For instance, Set-Cookie: illegalCookie=‘{“key1”:”value1”,”key2”:234,”key3”:true}’; Path=/; HttpOnly was treated as a valid value because of Jetty 9’s CookieCutter.

This is a snippet which shows how the characters were treated originally in Jetty 9

case ';':
case ',':
    if (tokenstart>=0)
        value = hdr.substring(tokenstart, tokenend+1);
    else
        value="";
    tokenstart = -1;
    invalue=false;
    break;

Link for the Source Code to see how the Cookie Cutter looked on this version

However, starting with Jetty 10.0.15 it was decided to be stricter and comply with the standard rfc6265 a bit more which caused the CookieCutter to be made even stricter.

You can see now that if you use a ‘,’ character in a Cookies value, it’ll throw an error.

case ',':
    if (COMMA_NOT_VALID_OCTET.isAllowedBy(_complianceMode))
        reportComplianceViolation(COMMA_NOT_VALID_OCTET, "Cookie " + cookieName);

Link to Jetty 10 code which handles “,” value by reporting an Error

Since Jetty 10 no longer allows commas in cookie values and with the old project using a logging style that doesn’t mention this in the migration guide, requests that used this cookie would only partially read (up until the “,” was encountered), leading to failures after the upgrade. No one would know why these failures happen because of other dependencies and even browsers still allow the use of objects in cookie values.

Luckily, this cookie value parsing issue is easy to fix by just encoding the data in Base64. This is even pointed out in the standard itself by the following: To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64