cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: ImageOpReader [ was; Community health]
Date Fri, 13 May 2005 09:48:09 GMT
Niclas Hedhman wrote:
> On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
> 
>>Le 13 mai 05, à 07:19, Niclas Hedhman a écrit :
>>
>>>Can you explain this a bit further? Because I have no clue what you
>>>think is
>>>the actual problem.
>>
>>I think Vadim sees a potential denial of service attack, if your system
>>allows one to generate images of a very large size.
> 
> 
> Our test shows that;
>  1. Image generation is in the sub-second range, even for really large images.
>     We hit the server 100 concurrent requests of sizes from 500-1500 px, and
>     couldn't register any particular load.
> 
>  2. No matter how big sizes you generate, the bandwidth that the system is
>     connected to will 'run out' way before the CPU gets bogged down. AFAIK, 
>     if I have a lot more bandwidth than you, I should be able to DoS your
>     system.
>     
>  3. If the image is too large then an OutOfMemoryError is the result (in 2ms)
>     which Tomcat recovers from.
> 
> In any event, I can't see this being anything different from any CPU intensive 
> webapps, and why it is any different from a complex XSLT transform. But I do 
> like to ehar from anyone who got such ideas.
> 
> 
> Since this came up, I will introduce a "max-size" parameter, with a default in 
> the 1000x1000 or so range.

Does it have the 'don't enlarge' option that is in the current image 
reader? That seems quite sensible to me.

Regards, Upayavira

Mime
View raw message