This probably affects all versions, not just 5.5.23.

It comes down to the utility class org.apache.tomcat.util.http.ContentType

It has the code:

    // Basically return everything after ";charset="
    // If no charset specified, use the HTTP default (ASCII) character set.
    public static String getCharsetFromContentType(String type) {

Which is basically lazy. It can't use everything after ";charset=". It *must* parse it and see if there is another ";"

Because if someone sets the Content-Disposition header in an XHR, it might BY NO FAULT OF THAT DEVELOPER end up as

Content-Type: multipart/form-data; charset=UTF-8; boundary=--------------------ext-ux-upload-boundary

That's taken directly from the Fiddler debugging tool. The browser (Firefox) INSERTED its encoding name (UTF-8 is mandated for XHRs) within the header which I specified. It did not append it, it INSERTED it.

Now, the character set ends up as "UTF-8; boundary=--------------------ext-ux-upload-boundary"