Only the commit Add Form and Multipart HttpMessageReader/Writer is expected to be reviewed in this PR, since the other one is already part of PR #1201.
@rstoyanchev I think there is currently a blocking point in MultipartHttpMessageWriter implementation (line 154 where there is the TODO). To summarise the issue, MultipartHttpMessageWriter follow the same design principle than Spring MVC FormHttpMessageConverter : it creates a custom MultipartHttpOutputMessage designed to write the part headers in the body using existing HttpMessageWriters.
Unlike Flux<DataBuffer> Encoder#encode((Publisher<T> inputStream, ...) which is a pure function, Mono<Void> ReactiveHttpOutputMessage#writeWith(Publisher<DataBuffer> body) API don't allow to get the transformed output to reuse it, so current implementation is adding MultipartHttpOutputMessage#getBody() with a hackish call to Mono#subscribe() in order to be sure that the Flux<DataBuffer> we retrieve is defined. That works (tests are green), but I guess that's not good in term of backpressure management and not very clean in term of software design.
Do you see a better way to do this given current ReactiveHttpOutputMessage contract ?
Comment From: rstoyanchev
Why don't you split the form reader/writer in a separate PR that can go through and give the multipart writer a little more time to figure out a better approach. It could be that we need to take a step back from how the Spring MVC converter does it.
Comment From: sdeleuze
This PR is now only for FormHttpMessageReader and FormHttpMessageWriter, I will create a dedicated PR for MultipartHttpMessageWriter later.
Comment From: rstoyanchev
This is now merged.