You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (Jira)" <ji...@apache.org> on 2025/04/15 09:40:00 UTC
[jira] [Updated] (SLING-12661) Potential origins of violations to the RequestDispatcher include API may run into OOM error on excessive recursions
[ https://issues.apache.org/jira/browse/SLING-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler updated SLING-12661:
-------------------------------------
Fix Version/s: (was: Engine 2.16.0)
> Potential origins of violations to the RequestDispatcher include API may run into OOM error on excessive recursions
> -------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-12661
> URL: https://issues.apache.org/jira/browse/SLING-12661
> Project: Sling
> Issue Type: Improvement
> Components: Engine
> Reporter: Remo Liechti
> Assignee: Remo Liechti
> Priority: Minor
>
> In case of excessive recursive calls, a huge stack of potential origins is generated (see SLING-12478).
> When using all those messages that sit in the RequestProgressTracker, a lot of memory is used to generate a log message that actually helps the developer to find the origin of the XSS violation. This may lead to OOM errors where the system cannot recover from. This seems to be especially critical for recursive calls where a servlet calls itself over and over again, building a bug amount of tracked messages that then later on need to be analyzed. As nobody will go through such a enormous stack, as well as it may get truncated during logging, make sure to use the last 500 messages of the RequestProgressTracker in the analysis of potential origins and put them into the log message instead.
> This way, we achieve a log message that can first of all, be logged properly and is still manageable to read and understood by the developer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)