RESTEasy Reactive Multipart struggles with non-file binary uploads about quarkus

[FroMage]

Also, I'm curious as to how the HTTP message looks like. Seems obvious we have a bug, because we assume it can be converted to a string, but I wonder what the content-type is set to, for this binary part.

https://www.rfc-editor.org/rfc/rfc7578.html#section-4.4 says the default content-type if missing is text/plain. So that's relevant.

[geoand]

https://www.rfc-editor.org/rfc/rfc7578.html#section-4.4 says the default content-type if missing is text/plain. So that's relevant.

So it seems like we are not taking into account the fact that the content is not text and automatically assuming it is.
We should fix this, but then that will also require (based on our current state of things), that we assign some kind of fileName to it.

[geoand]

#38714 should take care of it

[quarkus-bot]

/cc @FroMage (resteasy-reactive), @geoand (resteasy-reactive), @stuartwdouglas (resteasy-reactive)

[geoand]

Thanks for the detailed report!

Could you please attach a sample application that behaves as you describe?
It will be really helpful in debugging the issue and adding a proper test when it comes time to fix it.

Thanks!

[technical-debt-collector]

I've smacked together a quick reproducer here: multipart-reproducer.zip

I've tried explicitly passing content-types, but the difference it makes from what I can tell is allowing the client to specify the charset to encode the String with. I.e. specifying ISO-8859-1 as the charset using
curl -v -H 'Content-Type: multipart/form-data' -F 'example=<./example.jpg;charset=ISO8859-1' http://localhost:8080/test
won't change anything, but
curl -v -H 'Content-Type: multipart/form-data' -F 'example=<./example.jpg;type="application/octet-stream";charset=ISO8859-1 http://localhost:8080/test
will. Providing ISO-8859-1 as opposed to the UTF-8 default would make the resulting server-side array length smaller, though still wrong.

[technical-debt-collector]

Wouldn't changing the type of FormValue:getType from String to byte[] suffice in order to handle all possible content types? I suppose one would still probably prefer some sort of file handling so as to handle large parts though

[geoand]

I am working on a fix now