Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multipart data is always read irrelevant of handler response #30590

Closed
wjtlopez opened this issue Jun 4, 2023 · 0 comments
Closed

Multipart data is always read irrelevant of handler response #30590

wjtlopez opened this issue Jun 4, 2023 · 0 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@wjtlopez
Copy link

wjtlopez commented Jun 4, 2023

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 4, 2023
@poutsma poutsma self-assigned this Jun 8, 2023
@poutsma poutsma added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jun 8, 2023
@poutsma poutsma added this to the 6.0.10 milestone Jun 8, 2023
@poutsma poutsma closed this as completed in c1fe571 Jun 8, 2023
poutsma added a commit that referenced this issue Jun 8, 2023
This commit provided a default implementation for ServerWebExchange::cleanupMultipart.

See gh-30590
mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
This commit ensures that any storage used for multipart handling only
gets cleaned up if multipart data is actually retrieved via
ServerWebExchange::getMultipartData.

Closes spring-projectsgh-30590
mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
This commit provided a default implementation for ServerWebExchange::cleanupMultipart.

See spring-projectsgh-30590
mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
This commit ensures that any storage used for multipart handling only
gets cleaned up if multipart data is actually retrieved via
ServerWebExchange::getMultipartData.

Closes spring-projectsgh-30590
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants