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
