[
https://issues.apache.org/jira/browse/WW-5723?focusedWorklogId=1040919&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1040919
]
ASF GitHub Bot logged work on WW-5723:
--------------------------------------
Author: ASF GitHub Bot
Created on: 11/Sep/26 12:17
Start Date: 11/Sep/26 12:17
Worklog Time Spent: 10m
Work Description: 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)
Issue Time Tracking
-------------------
Worklog Id: (was: 1040919)
Time Spent: 40m (was: 0.5h)
> REST plugin does not bound the request body read in ContentTypeInterceptor
> --------------------------------------------------------------------------
>
> Key: WW-5723
> URL: https://issues.apache.org/jira/browse/WW-5723
> Project: Struts 2
> Issue Type: Improvement
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.12.0, 7.4.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h2. Summary
> {{ContentTypeInterceptor}} reads the request body with no length limit, while
> the two sibling body reads in the framework are bounded. This issue applies
> the same limit to the REST plugin.
> h2. Current behaviour
> {{ContentTypeInterceptor.intercept}} checks {{request.getContentLength() >
> 0}} and then hands {{request.getInputStream()}} to the selected
> {{ContentTypeHandler}}, which reads it to the end. Neither the interceptor
> nor {{RestConstants}} defines a maximum length.
> The JSON plugin bounds its equivalent read with {{struts.json.maxLength}}
> (default 2 MB), and {{CspReportAction}} bounds its read with
> {{struts.csp.report.maxSize}}. The REST plugin has no counterpart.
> h2. Proposed change
> Add {{struts.rest.content.maxLength}}, defaulting to 2 MB to match the JSON
> plugin, injected into {{ContentTypeInterceptor}} as a framework constant.
> Enforce it on the read itself by wrapping the reader handed to the handler,
> so a body exceeding the limit is rejected while being read, independent of
> the declared Content-Length.
> A configured value outside a sane range is ignored with a warning and the
> default kept, as {{CspReportAction}} does.
> The existing {{getContentLength() > 0}} condition is unchanged.
> h2. Compatibility notes
> A request whose body exceeds the configured limit is rejected rather than
> processed. Applications that accept larger bodies through the REST plugin
> need to raise {{struts.rest.content.maxLength}}.
> Applies to both maintenance lines.
> Reported by n0mi1k.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
