The client ignores content type when using byte arrays in multipart data about aleph HOT 3 CLOSED

Hello Eugene,

Thank you for the feedback and the issue.
I might be able to have a look during the week-end.
Whether you can't wait, do not hesitate to open a pull request.

from aleph.

@arnaudgeiser and @DerGuteMoritz are probably more familiar with this part of the code.

Looking at encode-request, it seems we ignore :mime-type if the part isn't a File, but that hardly seems fair. It seems like we should be able to manually add a Content-Type header for those parts if supplied.

After looking at the Netty MemoryFileUpload class's behavior, there are a few more consequences to saying a part is a file than just getting a Content-Type header. It's possibly ok, but needs a closer look. We'd have to assign a file name, and it'll add Content-Disposition headers (as well as other headers) which the other end may treat differently from the existing behavior.

Continuing to use an Attribute and manually adding the Content-type header might be all we need, if we can do that. However, I was looking, and I don't see any way to add extra headers to Attribute parts in Netty, so MemoryFileUpload (or MixedFileUpload if we want to set an upper limit on how much memory to consume) may be our only options.

from aleph.

An issue is open regarding this on Netty (Eugene added a comment already) [1].
I also had a look and using MemoryFileUpload might be the correct approach.
I spent a little bit of time on VertX (found nothing), Micronaut [2] and Reactor Netty [3].

[1] : netty/netty#6800
[2] : https://github.com/micronaut-projects/micronaut-core/blob/1d8a98ba11ec0d6d280812b9a433f2e23ba3dcca/http-client-core/src/main/java/io/micronaut/http/client/multipart/InputStreamPart.java
[3] : https://github.com/reactor/reactor-netty/blob/0296f6e03669c7337b7e9cd341461ee071d8e922/reactor-netty-http/src/main/java/reactor/netty/http/client/HttpClientFormEncoder.java#L292

from aleph.