Description
When upgrading from Spring Boot 3.5.11 to 4.0.3, a multipart request containing multiple parts starts failing with a 413 Payload Too Large error.
I investigated the issue and found that it can be resolved by configuring the Tomcat limit for the number of parts (e.g., setting server.tomcat.max-part-count). I assume this might be due to a stricter default value introduced in the underlying Tomcat version used by Spring Boot 4.0.x.
I did a text search in the Spring Boot 4.0 Migration Guide but couldn't find any mention of this breaking change or the new default limit. It is possible that it is documented somewhere and I simply missed it. However, if that is the case, it might be a bit difficult for developers to discover.
My Question & Proposal:
I would like to ask if this change in default behavior is a bug, an intentional change, or perhaps an issue with how my test is written?
- If it is a bug: Please let me know if there is anything I can do to help fix it.
- If it is intentional: I strongly suggest adding a clearer mention of it in the Spring Boot 4.0 Migration Guide. Without a prominent note, developers might be surprised and confused by sudden 413 errors after upgrading.
- If my test implementation is incorrect/outdated for 4.0.x: I would greatly appreciate any guidance on the proper way to construct this multipart request in the new version.
Steps to Reproduce
I have created a minimal reproducible example repository here:
https://github.com/shayFoo/spring-multi-part
This repository contains two separate folders to demonstrate the difference in behavior:
demo-multipart-3-5-11 folder: The test passes successfully (returns 200).
demo-multipart-4-0-3 folder: The exact same test fails (returns 413).
How to reproduce:
- Clone the repository:
git clone https://github.com/shayFoo/spring-multi-part.git
- Run the test in the
demo-multipart-4-0-3 project. You will observe the 413 Payload Too Large error.
- Run the test in the
demo-multipart-3-5-11 project. You will see it passes without issues.
Expected Behavior
The test in 4.0.3 should pass with a 200 OK status, just like it does in Spring Boot 3.5.11.
If the default multipart limit has intentionally changed in 4.0.x, it should be explicitly and prominently mentioned in the migration guide along with the relevant property (server.tomcat.max-part-count) to configure it.
Actual Behavior
The test fails with a 413 Payload Too Large error in Spring Boot 4.0.3.
Workaround
Explicitly setting server.tomcat.max-part-count in application.properties (or YAML) resolves the issue in 4.0.3.
Description
When upgrading from Spring Boot 3.5.11 to 4.0.3, a multipart request containing multiple parts starts failing with a
413 Payload Too Largeerror.I investigated the issue and found that it can be resolved by configuring the Tomcat limit for the number of parts (e.g., setting
server.tomcat.max-part-count). I assume this might be due to a stricter default value introduced in the underlying Tomcat version used by Spring Boot 4.0.x.I did a text search in the Spring Boot 4.0 Migration Guide but couldn't find any mention of this breaking change or the new default limit. It is possible that it is documented somewhere and I simply missed it. However, if that is the case, it might be a bit difficult for developers to discover.
My Question & Proposal:
I would like to ask if this change in default behavior is a bug, an intentional change, or perhaps an issue with how my test is written?
Steps to Reproduce
I have created a minimal reproducible example repository here:
https://github.com/shayFoo/spring-multi-part
This repository contains two separate folders to demonstrate the difference in behavior:
demo-multipart-3-5-11folder: The test passes successfully (returns 200).demo-multipart-4-0-3folder: The exact same test fails (returns 413).How to reproduce:
git clone https://github.com/shayFoo/spring-multi-part.gitdemo-multipart-4-0-3project. You will observe the413 Payload Too Largeerror.demo-multipart-3-5-11project. You will see it passes without issues.Expected Behavior
The test in 4.0.3 should pass with a
200 OKstatus, just like it does in Spring Boot 3.5.11.If the default multipart limit has intentionally changed in 4.0.x, it should be explicitly and prominently mentioned in the migration guide along with the relevant property (
server.tomcat.max-part-count) to configure it.Actual Behavior
The test fails with a
413 Payload Too Largeerror in Spring Boot 4.0.3.Workaround
Explicitly setting
server.tomcat.max-part-countinapplication.properties(or YAML) resolves the issue in 4.0.3.