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
MAX_ENTITY_SIZE or max-http-post-size configuration parameters are overridden by spring.servlet.multipart.max-request-size when using Undertow #18555
Comments
Thank you for the sample, @jansu76. In looking at it I have just learned that Undertow has two ways of configuring the maximum entity size for a request. The For many Boot apps where all requests are handled by a servlet, this means that setting We'll need to straighten this out but I'm not yet sure how best to do that. In the meantime setting |
Before we proceed on this, we should open an Undertow issue as the current behaviour may not be intentional. It feels wrong that a multi-part specific piece of configuration affects all requests to a servlet. |
I've opened UNDERTOW-1601. |
Just to comment, using Ideally we would have perhaps
in our configuration. But I understand https://issues.jboss.org/browse/UNDERTOW-1601 is needed for this to be possible, fingers crossed it gets timely resolution! |
UndertowOptions has MULTIPART_MAX_ENTITY_SIZE and javadocs hint that you should be able to use it to what I am after
I tried to test with a modified version of the code posted in UNDERTOW-1601
but to my disappointment both normal posts and multipart posts were limited to the same MAX_ENTITY_SIZE value of 20 bytes. Not sure if this gives any new information, but posting it in any case. |
That's an interesting finding, @jansu76. Thank you. The presence of a multipart config element may still cause problems, but I wonder if there's something Undertow-specific that we can do here. |
Doing something Undertow-specific in Boot itself isn't straightforward, but there is a workaround that you can use in your own application by adding a couple of beans. First we define a custom @Bean
public MultipartConfigElement multipartConfigElement(MultipartProperties properties) {
MultipartConfigFactory factory = new MultipartConfigFactory();
PropertyMapper map = PropertyMapper.get().alwaysApplyingWhenNonNull();
map.from(properties::getFileSizeThreshold).to(factory::setFileSizeThreshold);
map.from(properties::getLocation).whenHasText().to(factory::setLocation);
return factory.createMultipartConfig();
} Then we customise Undertow to set its max entity size and multipart entity size: @Bean
public WebServerFactoryCustomizer<UndertowServletWebServerFactory> undertowCustomizer() {
return (undertowFactory) -> undertowFactory.addBuilderCustomizers((builder) -> {
builder.setServerOption(UndertowOptions.MULTIPART_MAX_ENTITY_SIZE, 52428800L);
builder.setServerOption(UndertowOptions.MAX_ENTITY_SIZE, 51200L);
});
} With changes similar to these in place, Undertow rejects the large post request as required, but does not reject a large multipart post. |
There's been no traction at all on the Undertow issue I opened 12 months ago. If this issue is important to you, please comment on or vote for the Undertow issue so that the team can prioritise it accordingly. Given the lack of traction on Undertow issues that we have raised such as UNDERTOW-1601 and UNDERTOW-1743 and the Undertow team choosing not to fix CVEs in 2.1 which GAed only 5 months ago, I think it's worth anyone using Undertow re-evaluating the benefits that attracted them to it. Bugs not being fixed and requiring minor upgrades to avoid security vulnerabilities would weigh very heavily for me against any other benefits. I'd want to be using a container with a maintenance approach that better met my needs. I'm moving this issue to the general backlog as it doesn't feel realistic to plan for a fix during 2.2.x's lifespan. As and when the necessary changes are made in Undertow we can schedule any work that is necessary in Boot to make use of them. |
A fix for UNDERTOW-1601 is coming in Undertow 2.2.9. Assigning this to 2.6.x so that we can see what, if anything, we can do/need to do on top of that fix. |
This works as expected with Undertow 2.2.9 without any other changes. The server side logs a warning:
And the client-side receives a 400 response (test script modified to invoke curl with
|
Tried with Spring Boot 2.1.3.RELEASE, 2.1.6.RELEASE, and 2.1.9.RELEASE.
Setting application property
server.undertow.max-http-post
or server optionUndertowOptions.MAX_ENTITY_SIZE
does not seem to work, when using Undertow.Detailed explanation at https://stackoverflow.com/questions/58222154/unable-to-use-undertowservletwebserverfactory-to-limit-max-entity-size
Minimal test repo to replicate the problem: https://github.com/jansu76/gs-spring-boot/tree/undertow-testing/complete
Diff to master to see what I have changed from https://github.com/spring-guides/gs-spring-boot:
spring-guides/gs-spring-boot@master...jansu76:undertow-testing
To test:
Script should do a large
POST
request to the application, which should be limited by Undertow max post size config. But it is not.It seems
UndertowServletWebServerFactory
sets port to 9090 butUndertowOptions.MAX_ENTITY_SIZE = 100
has noeffect. server.undertow.max-http-post-size=10
sets some max entity size values for some time, but those are overwritten inio.undertow.servlet.handlers.ServletInitialHandler.handleRequest:181
which overwritesmaxEntitySize
value from 10 to 10485760.The text was updated successfully, but these errors were encountered: