Polishing contribution
Includes small refactoring in DefaultServerWebExchange and adjustment of initMultipartData to get involved for any "multipart/" prefixed media type. In addition, "multipart/related" is now in the list of media types supported by FormHttpMessageConverter, which aligns it with MultipartHttpMessageReader. Closes gh-29671
This commit is contained in:
@@ -614,7 +614,7 @@ The `DefaultServerWebExchange` uses the configured `HttpMessageReader` to parse
|
||||
|
||||
The `DefaultServerWebExchange` uses the configured
|
||||
`HttpMessageReader<MultiValueMap<String, Part>>` to parse `multipart/form-data`,
|
||||
`multipart/mixed` and `multipart/related` content into a `MultiValueMap`.
|
||||
`multipart/mixed`, and `multipart/related` content into a `MultiValueMap`.
|
||||
By default, this is the `DefaultPartHttpMessageReader`, which does not have any third-party
|
||||
dependencies.
|
||||
Alternatively, the `SynchronossPartHttpMessageReader` can be used, which is based on the
|
||||
@@ -805,7 +805,7 @@ consistently for access to the cached form data versus reading from the raw requ
|
||||
==== Multipart
|
||||
|
||||
`MultipartHttpMessageReader` and `MultipartHttpMessageWriter` support decoding and
|
||||
encoding "multipart/form-data", "multipart/mixed" and "multipart/related" content.
|
||||
encoding "multipart/form-data", "multipart/mixed", and "multipart/related" content.
|
||||
In turn `MultipartHttpMessageReader` delegates to another `HttpMessageReader`
|
||||
for the actual parsing to a `Flux<Part>` and then simply collects the parts into a `MultiValueMap`.
|
||||
By default, the `DefaultPartHttpMessageReader` is used, but this can be changed through the
|
||||
|
||||
Reference in New Issue
Block a user