[ 
https://issues.apache.org/jira/browse/SLING-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625645#action_12625645
 ] 

Carsten Ziegeler commented on SLING-601:
----------------------------------------

Yes, I think having both limits makes sense - as pointed out, the current 
mechanism checks the recursion level where a value of 50 should really be 
sufficient.
In addition couting the total number of includes and limiting them (to 1000) 
makes sense.
However, it would be great to have this configurable - I can imagine that if 
you're building heavy portal sites the limits should be higher.

> Request Inclusion Counter operating too rigid
> ---------------------------------------------
>
>                 Key: SLING-601
>                 URL: https://issues.apache.org/jira/browse/SLING-601
>             Project: Sling
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: Engine 2.0.2
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: Engine 2.0.4
>
>
> The SlingMainServlet implements a recursion level counter to prevent 
> recursions going too deep in the checkRecursionLevel method. What this method 
> does is incrementing a counter stored as a request attribute everytime 
> RequestDispatcher.include is called (by whatever means).
> The drawback of this mechanism is, that the counter is only incremented and 
> never decremented after an inclusion returns. This in fact is not a recursion 
> level counter but a counter limiting the number of times 
> RequestDispatcher.include may be called. Another drawback of this is, that 
> the implementation is overcomplicated, because the RequestData object created 
> for each request keeps a stack of a inclusions and hence could easily 
> implement a real recursion level checker by just checking the size of the 
> stack.
> I think, we should drop the SlingMainServlet.checkRecursionLevel method 
> altogether and replace it with a new RequestData.checkAbort method which 
> throws in case any of two cases occurrs:
>    * Recursion Level is too deep (50 seems like useful)
>    * Number of includes exceeds a given number (something like 1000 or more ?)
> In addition the Exception should be made public in the Sling engine module 
> such that users of any include mechanism could handle it if need be.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to