Besides multipart/form-data, there are two other multipart media types in use:
multipart/mixed, as defined in RFC 1341, and used in OData Batch Processingmultipart/related, as defined in RFC 2387, and used in Google Cloud Multipart Upload.
These have different properties than multipart/form-data, for instance in that they do not require a Content-Dispostion header for each part.
Furthermore, it seems that OData relies on nested multipart/mixed structures, where the outer batch part can contain a changeset that is in itself a multipart consisting of changes.
Not having done a full investigation, it appears that there are a number of issues with our current WebFlux multipart support that prevents us from fully supporting multipart/mixed and multipart/related:
- The DefaultPartHttpMessageReader is not capable of reading nested multipart messages.
- The MultipartHttpMessageWriter and PartEventHttpMessageWriter are not capable of writing nested multipart messages, except in a raw form.
- The Part and PartEvent interfaces expose a name property that reflects the Content-Disposition name, but which only makes sense in multipart/form-data.
- The MultipartHttpMessageWriter and PartEventHttpMessageWriter write a Content-Disposition header, which it only needed in multipart/form-data.
This issue was created to gather all research done on multipart/mixed and multipart/related done so far, and to see how much interest there is in the community for Spring Framework to fully support these multipart types.
Comment From: JoshukLite
In case when WebFlux is used as client to connect 3rd party applications that might be useful to have such feature.
For example if application need to connect 3rd party API using xAPI documentation where in some cases it should use strictly multipart/mixed media type - xAPI documentation reference about multipart/mixed
Comment From: imanolie-bwi
Any idea when this will be implemented? Otherwise ideas on how to overcome it until multipart/related gets implemented in Spring?