Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
From: Niclas Hedhman <niclas@hedhman.org>
To: dev@cocoon.apache.org
Subject: ImageOpReader [ was; Community health]
Date: Fri, 13 May 2005 15:27:56 +0800
User-Agent: KMail/1.7.2
References: <2f44faadc4a27ef74ba7ef13b742cdd9@efurbishment.com>
 <200505131319.23066.niclas@hedhman.org>
 <2bf9d1e941ee342edf35ce26c10e821a@apache.org>
In-Reply-To: <2bf9d1e941ee342edf35ce26c10e821a@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200505131527.56462.niclas@hedhman.org>

On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
> Le 13 mai 05, =E0 07:19, Niclas Hedhman a =E9crit :
> > 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 imag=
es.
    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,=
=20
    if I have a lot more bandwidth than you, I should be able to DoS your
    system.
   =20
 3. If the image is too large then an OutOfMemoryError is the result (in 2m=
s)
    which Tomcat recovers from.

In any event, I can't see this being anything different from any CPU intens=
ive=20
webapps, and why it is any different from a complex XSLT transform. But I d=
o=20
like to ehar from anyone who got such ideas.


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


Cheers
Niclas