You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/08/01 08:06:00 UTC
[jira] [Work logged] (WW-5666) Apply input length limits consistently when reading request bodies
[ https://issues.apache.org/jira/browse/WW-5666?focusedWorklogId=1033302&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1033302 ]
ASF GitHub Bot logged work on WW-5666:
--------------------------------------
Author: ASF GitHub Bot
Created on: 01/Aug/26 08:05
Start Date: 01/Aug/26 08:05
Worklog Time Spent: 10m
Work Description: lukaszlenart merged PR #1822:
URL: https://github.com/apache/struts/pull/1822
Issue Time Tracking
-------------------
Worklog Id: (was: 1033302)
Time Spent: 1h 40m (was: 1.5h)
> Apply input length limits consistently when reading request bodies
> ------------------------------------------------------------------
>
> Key: WW-5666
> URL: https://issues.apache.org/jira/browse/WW-5666
> Project: Struts 2
> Issue Type: Improvement
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.11.0, 7.3.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> h2. Summary
> Two request-body reading paths apply input limits less consistently than the rest of the framework. This issue makes the JSON input length limit apply uniformly while reading, and gives the CSP reporting path a configurable limit of its own.
> h2. Current behaviour
> *JSON plugin*
> {{JSONUtil.deserializeInput(Reader, int)}} accumulates input a line at a time and compares the accumulated length against {{struts.json.maxLength}} between lines. The limit is therefore applied after input has been accumulated rather than while it is being read, which makes enforcement less predictable than the other configured limits in the plugin ({{struts.json.maxDepth}}, {{struts.json.maxElements}}, {{struts.json.maxStringLength}}, {{struts.json.maxKeyLength}}).
> *CSP reporting*
> {{CspReportAction}} reads the submitted report body with a single {{readLine()}} call and has no limit of its own. Unlike the JSON path, there is no way for an application to declare how large a report it is prepared to accept, and no limit is applied by default.
> h2. Proposed change
> * Evaluate the JSON input length limit as input is read, in fixed-size chunks, so that enforcement does not vary with the structure of the input.
> * Read the CSP report body up to a limit, defaulting to 8192 characters, exposed as a {{maxReportSize}} property on {{CspReportAction}} so applications can tune it. A report above the limit is discarded with a warning rather than processed.
> h2. Compatibility notes
> *JSON plugin*
> * Line terminators are no longer stripped while reading. They are insignificant whitespace between tokens, so parsing is unaffected.
> * An unescaped control character appearing inside a JSON string value is now preserved in the parsed value rather than silently removed. Such input is not valid JSON; applications relying on the previous silent removal may observe different values.
> *CSP reporting*
> * {{processReport}} now receives the whole body up to the limit rather than only its first line.
> * An empty body is passed as an empty string rather than {{null}}.
> h2. Notes
> {{JSONUtil}} is already marked for removal in 8.0.0 under WW-5619. This change targets the existing class and does not affect that plan.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)