cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
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

View raw message