On 11 Jan 2010, at 19:50, Felix Meschberger wrote:

> Hi Simon,
> 
> On 11.01.2010 19:01, Simon Gaeremynck wrote:
>> Yes, I guess that could work.
>> 
>> But then you can still do node.1000000.json which results in the same
>> thing.
>> 
>> I took the liberty to write a patch which checks the amount of resources
>> will be in the result.
>> If the result is bigger than a pre-defined OSGi property (ex: 200
>> resources) it will send a 206
>> partial content with the dump of 200 resources and will ignore the rest.
>> 
>> It can be found at http://codereview.appspot.com/186072
> 
> This looks interesting. Tough instead of limiting the number of
> reosources to return, I would limit the number of levels to return.
> 
> WDYT ?

with 4 levels its quite easy to get to 4E9 files (255^^4) which would take 
quite a lot of time to send. Simon works in the same office and we chatted 
about this when we thought it might be possible to solve in Sakai, but I think 
its probably important for Sling as well.
Ian



> 
> Regards
> Felix
> 
>> 
>> Simon
>> 
>> 
>> On 10 Jan 2010, at 16:43, Eric Norman wrote:
>> 
>>> One option would be to register your own script (or servlet) that also
>>> matches the same selector [+extension].  Since your script would be a
>>> closer
>>> match than the default get servlet, it should use your script instead.
>>> 
>>> For example, create an esp script @
>>> apps/sling/servlet/default/infinity.json.esp
>>> 
>>> The content of the infinity.json.esp script could just send a 404
>>> error to
>>> the response.
>>> <%
>>>  response.sendError(404);
>>> %>
>>> 
>>> 
>>> On Fri, Jan 8, 2010 at 9:18 AM, Simon Gaeremynck
>>> <[email protected]>wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Is there any way of disable or restricting the node.infinity.json
>>>> selector.
>>>> We have quite a bit of content and when we do a .infinity.json on our
>>>> root
>>>> node this causes the server to grind to a halt.
>>>> It looks like it's internal to JsonRendererServlet but I might be
>>>> overseeing something.
>>>> 
>>>> This looks to me like a potential hole for a DOS attack.
>>>> 
>>>> 
>>>> Kind regards,
>>>> 
>>>> Simon
>>>> 
>> 
>> 

Reply via email to