Binary data inside mulitpart/form-data is being converted to String

If no "filename" parameter is provided in the Content-Disposition header of a form-data part, the part's body will be automatically converted to a String.

Reference methods:
io.undertow.server.handlers.form.MultiPartParserDefinition#beginPart
io.undertow.server.handlers.form.MultiPartParserDefinition#endPart

This is better explained with an example, assume we want to send an image/jpeg inside a multipart/mixed inside a multipart/form-data, like this:

POST / HTTP/1.1
Content-Type: multipart/form-data; boundary=111111

--111111
Content-Disposition: form-data; name="form-part"
Content-Type: multipart/mixed; boundary=222222

--222222
Content-Disposition: attachment; name="example.jpeg"
Content-Type: image/jpeg

[jpeg_content]
--222222--

--111111--

(There is only 1 part per multipart "block", irrelevant headers and the image binary contents were omitted just for the sake of readability. The issue still exists if there are multiple parts per multipart "block").

If we try to access the "form-part" body content through, for example, the getInputStream() of the Servlet's Part implementation (PartImpl) the binary content of the "example.jpeg" image will be incorrect because the InputStream is being backed up by the String created at io.undertow.server.handlers.form.MultiPartParserDefinition#endPart:

data.add(currentName, new String(contentBytes.toByteArray(), charset), headers);

Instead of receiving the image's binary data we will be receiving the String encoded version of that data.

If a "filename" parameter is added to the Content-Disposition header (like this: Content-Disposition: form-data; name="form-part"; filename="form-part") the issue will not happen as the part's body InputStream will be backed up by an actual file and not by a String, avoiding the encoding problem. Since the "filename" is not a mandatory parameter, this seems to be an inconsistent behaviour.

In my opinion, I see no reason to convert to a String if no "charset" parameter is specified in the part's Content-Type header. In those cases, storing the binary content in a random temporary file seems to be the best approach.