cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: ImageOpReader [ was; Community health]
Date Fri, 13 May 2005 12:21:37 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.

I used 4096 :-) Not sure if it will accept larger image size as well.


>  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.

DoS is not necessarily overloading CPU - overloading your channel is DoS too. If 
your channel has lots of bandwidth, then DDoS is the way to go :-)


>  3. If the image is too large then an OutOfMemoryError is the result (in 2ms)
>     which Tomcat recovers from.

So that means picking the right size of image... Not sure how healthy large does 
of OOME, though.


> 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.

XSLT transformrs usually do not have bandwidth / computational dependencies on 
the request parameters.

On your place, I personally would not accept arbitrary image size in the URL - 
even if I have it in the URL. I would limit access only to image sizes I want to 
allow. This reduces chance for abuse - and increases chance for cache hit 
(suppose you have zoom control with 5 poisitions and 1000 positions: latter have 
higher probability of cache hit, former - higher probability of cache miss).


> Since this came up, I will introduce a "max-size" parameter, with a default in 
> the 1000x1000 or so range.

Good idea.

OT: Why square? Aren't photos ratio 4:3 or some such?

Vadim

Mime
View raw message