Add formParamsMaxSize to FormEncodingProvider and estimate form params count before decoding / parsing

[reta]

Add formParamsMaxSize to FormEncodingProvider and estimate form params count before decoding / parsing

[Copilot]

🟡 Changes recommended

The new early part-count estimation and the new large-body systest have correctness/robustness issues that should be addressed before merging.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR introduces configurable limits for JAX-RS application/x-www-form-urlencoded request handling by adding a maximum form-body size configuration to FormEncodingProvider, and by adding an early estimate of form parameter count before splitting/decoding to mitigate excessive input.

Changes:

• Add formParamsMaxSize to FormEncodingProvider and enforce it when reading the request body.
• Add a system-property-backed default max form-body size in FormUtils, plus a new readBody(..., maxSize) overload.
• Add systests covering “too many form params” and “too large form body”.

File summaries

File	Description
systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java	Adds systests for form param count and form body size limit scenarios.
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/FormUtils.java	Adds default max form size, a size-limited body reader, and an early param-count estimate prior to splitting/decoding.
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/FormEncodingProvider.java	Adds configurable formParamsMaxSize and uses it when reading form bodies.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[coheigea]

@reta Can you check these comments please:

High: the vulnerable @FormParam path remains unchanged.

The PR limits reads only inside FormEncodingProvider. However, ordinary @FormParam processing is handled directly by JAXRSUtils.processFormParam, which still does:

FormUtils.readBody(entityStream, enc) using the uncapped overload.
FormUtils.populateMapFromString(...).
postBody.split("&") before the parameter-count check.
Relevant unchanged paths:

JAXRSUtils.java:1201
FormUtils.java:119
FormUtils.java:137
Therefore, an endpoint using @FormParam can still receive an unbounded body and reach the original split-before-check allocation. The PR's formParamsMaxSize setter is not applied to this path.

The servlet request adapter has the same issue:

HttpServletRequestFilter.java:122
Medium: the new provider-side size limit still permits excessive memory allocation.

The changed provider path now calls the capped overload, but its default is 100 MiB. readBody materializes the body into a ByteArrayOutputStream, then creates another byte array with toByteArray(), and then creates a decoded String. A request near the configured limit can therefore require substantially more than 100 MiB of transient memory before the parser rejects it.

Also, IOUtils.copy writes the input chunk before checking whether maxSize has been exceeded:

IOUtils.java:218
This is a bounded allocation compared with the original unbounded behavior, but it is not a robust low-memory default. On a 128 MiB heap, a body approaching the 100 MiB default can still cause memory pressure or OutOfMemoryError.

[reta]

The PR limits reads only inside FormEncodingProvider. However, ordinary @FormParam processing is handled directly by JAXRSUtils.processFormParam, which still does:

Thanks @coheigea . yes, I am going through though form param handling, starting with FormEncodingProvider only (that was really an intent), will send pull requests for other flows (sorry, have limited time). Thanks!