Make WebFlux multipart support fully Reactive [SPR-17122]

[spring-projects-issues]

Sébastien Deleuze opened SPR-17122 and commented

Spring Framework 5.0 and 5.1 provides support for reactive multipart leveraging Synchronoss nio-multipart library which comes with several limitations. Spring WebFlux feeds data to the parser, which then provides a callback when the entire content for the part is ready, potentially creating temporary files when the content is too big to avoid consuming too much memory. These limitations mainly comes from the fact that their StreamStorage abstraction is based on InputStream / OutputStream.

As proposed initially by Arjen Poutsma, we should probably write our own reactive multipart implementation to overcome these limitation and provide a fully reactive behavior where the content of the file is Reactive Streams compliant (bytes comes to the user as they are received) in order to give more control to the user. If we provide this, I tend to think that we don't have to create temporary files.

---

Issue Links:

• Race-Condition in Multipart upload proxy scenario [SPR-16639] #21180 Race-Condition in Multipart upload proxy scenario

[spring-projects-issues]

Rossen Stoyanchev commented

There are two styles of usage, one via Flux<Part> with @RequestBody and other is through a MultiValueMap<String, Part> which could happen through data binding, or via @RequestPart.

For reading via Flux using memory with back pressure makes sense. The MultiValueMap usage however could put put a burden on memory if content is over a certain size. We could recommend using Flux for reading larger content, and otherwise put a limit on input buffering. However there might still be a case for temp files, e.g. data binding with a named FilePart bound onto a field.