lukaszlenart opened a new pull request, #1913: URL: https://github.com/apache/struts/pull/1913
Fixes [WW-5723](https://issues.apache.org/jira/browse/WW-5723) 6.x port of #1912. `ContentTypeInterceptor` handed `request.getInputStream()` to the content-type handler with no length limit, while the JSON plugin bounds the same read with `struts.json.maxLength` and `CspReportAction` with `struts.csp.report.maxSize`. This applies the same limit to the REST plugin on the 6.x line. ## What changes - New constant `struts.rest.content.maxLength`, default `2097152` (matching the JSON plugin), declared in the plugin's `struts-plugin.xml` and injected into `ContentTypeInterceptor` via `@Inject(required = false)`. Blank, non-numeric or sub-1 values are ignored with a warning and the default kept. - The handler receives a `BoundedReader` — a `FilterReader` that counts characters and fails once the limit is passed. On overflow the interceptor throws the new `RequestBodyTooLargeException` (a `StrutsException`), and the action is never invoked. - The `getContentLength() > 0` gate is unchanged. ## Differences from the main-line change None in behaviour. The setter, the `intercept()` try/catch and post-call check, the `BoundedReader` and the exception class are identical to #1912. The 6.x interceptor has no `@StrutsParameter` authorization paths, so the change is smaller here: a single `handler.toObject(...)` call is wrapped rather than three. The design notes in #1912 apply unchanged — bound the read rather than the header, lazy rather than buffered so no-op handlers leave the body untouched, one exception type regardless of which handler wrapped the reader's failure, and fail-closed when a handler swallows it. ## Tests `ContentTypeInterceptorTest` gains the same ten tests as #1912: over-limit body rejected before the action runs, body exactly at the limit passed in full, over-limit body not read to the end, blank / non-numeric / sub-1 configuration keeping the default, a handler that ignores the reader leaving the body unread, a handler that swallows the reader's failure still being rejected, a handler failure under the limit propagating as the same object, and `skip()` counting against the limit. The two existing encoding tests asserted the handler received an `InputStreamReader`; they now assert the decoded content, with the ASCII case changed to ISO-8859-1 so the assertion discriminates. REST plugin suite: 90 tests, 0 failures. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
