I am using the latest version of spring boot dependencies 3.1.0
and the issue exists specifically in org.springframework.web.server.adapter.HttpWebHandlerAdapter
in spring-web-6.0.9
.
When invoking an API defined by a RouterFunction<ServerResponse>
accepting MediaType.MULTIPART_FORM_DATA
and simply returning ServerResponse.ok().build()
within the handler, if you set logging.level.org.springframework=TRACE
you will see that all contents supplied in the request are parsed, read into memory and written to a file.
I am adding a large_file.mp4
to my request and even though my handler is not reading the body, Spring is still parsing the multipart file. This happens because of line 328
private Mono<Void> cleanupMultipart(ServerWebExchange exchange) {
return exchange.getMultipartData()
.onErrorResume(t -> Mono.empty()) // ignore errors reading multipart data
.flatMapIterable(Map::values)
.flatMapIterable(Function.identity())
.flatMap(this::deletePart)
.then();
}
My file is large so it is easy to notice the delay in returning 200 OK
and in the logs you can see
2023-06-04T17:29:50.617+01:00 TRACE 38144 --- [oundedElastic-3] o.s.http.codec.multipart.PartGenerator : Emitting: DefaultFilePart{video (large_file.mp4)}
At the very least this is delaying the request being handled to completion even if the handler returns before needing to parse the request, for example for validation reasons.
In fact this also occurs even if the API invoked isn't expecting to accept a multipart file so could easily be used to abuse/overload an application, specially as spring.webflux.multipart.maxDiskUsagePerPart
on DefaultPartHttpMessageReader
is defaulted to not having a maximum.