Currently there is no option to pass Flux<Part> as body via WebClient. This pr extends WebClient functionality and allows accept Flux<Part> as body.
Comment From: kptfh
@rstoyanchev Hi. Do you mean to include this code into MultipartHttpMessageWriter?
Initially I started with this approach but code get over-complicated so I decided to introduce small atomically tested change that meets single responsibility criteria.
IMHO I think that MultipartHttpMessageWriter should be split as it responsible for Form data encoding and multipart data and has a lot of ifs.
Comment From: rstoyanchev
No this can't be done in the current MultipartHttpMessageWriter because it's parameterized by MultiValueMap<String, ?>.
However, and I haven't tried it, I think a base class can be extracted out from the current MultiparthttpMesageWriter with most of the logic for writing parts. So this new PartHttpMessageWriter (or perhaps StreamingMultipartHttpMessageWriter) could then extend from the same base class and both should then be pretty minimal, with most of the logic in the base class.
Comment From: rstoyanchev
IMHO I think that MultipartHttpMessageWriter should be split as it responsible for Form data encoding and multipart data and has a lot of ifs.
MultipartHttpMessageWriter merely delegates to FormHttpMessageWriter so it acts as a composite, that's about as simple as it gets. There is a reason for that, because in write we can tell if the data is multipart or not even if the MediaType is not present. We can't do the same via canWrite.
Also from the Javadoc
* <p>This writer can be configured with a {@link FormHttpMessageWriter} to
* delegate to. It is the preferred way of supporting both form data and
* multipart data (as opposed to registering each writer separately) so that
* when the {@link MediaType} is not specified and generics are not present on
* the target element type, we can inspect the values in the actual map and
* decide whether to write plain form data (String values only) or otherwise.