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_DATAand 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.