Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE:  Re: mod_reqtimeout backport
Date: Wed, 13 Jan 2010 16:21:45 +0100
Message-ID: 
 <99EA83DCDE961346AFA9B5EC33FEC08B03418BC9@VF-MBX11.internal.vodafone.com>
In-Reply-To: A<yuamy0i3wrc.fsf@pobox.com>
Thread-Topic: Re: mod_reqtimeout backport
Thread-Index: AcqUXL7vtu5JGmTLRaK72/M0knwZPgABuSfg
References: 
 <20100109195247.B53EC238899B@eris.apache.org><yuapr5fgnkp.fsf@slappy.raleigh.ibm.com><201001130030.37405.sf@sfritsch.de>
 A<yuamy0i3wrc.fsf@pobox.com>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Dan Poirier
> Sent: Mittwoch, 13. Januar 2010 15:28
> To: dev@httpd.apache.org
> Subject: Re: mod_reqtimeout backport
>=20
> Stefan Fritsch <sf@sfritsch.de> writes:
>=20
> > I am not particularly happy about the syntax, yet. I just=20
> had the idea=20
> > to have one keyword xxx that can optionally accept a range,=20
> instead of=20
> > two keywords xxxinit and xxxmax:
> >
> > 	Header=3D30
> > 	Body=3D5-50 BodyMinRate=3D500
> >
> > or=20
> >
> >     Header=3D5-20,minrate=3D500
> >     Body=3D5-50,minrate=3D500
> >
> > but the combination
> >
> >     Header=3D5,minrate=3D1000
> >
> > is less clear. Maybe make the '-' mandatory in this case:
> >
> >     Header=3D5-,minrate=3D1000
> >
> > Any opinions or better ideas?
> >
> > One could also rename RequestTimeout into=20
> RequestReadTimeout if that=20
> > makes it easier to understand.
>=20
> We might simplify the model by not exposing the internal extending of
> the timeout.  Just let the admin specify an overall max time,=20
> a minimum
> rate, or both:
>=20
>   HeaderTimeout: Maximum seconds to read the entire header.
>=20
>   HeaderMinRate: Minimum rate (bytes/second) allowed when reading the
>   request header.  If the rate drops below this, the request is timed
>   out.
>=20
> We'd enforce both if specified.  In that case HeaderTimeout would act
> like headermax.  Internally we'd probably implement HeaderMinRate by
> gradually extending a timeout, but we wouldn't be tied to that.

But that would result in different behaviour, wouldn't it?

e.g. with init timeout set to 10 max timeout set to 30 and minrate set =
500
the client can wait for 10 seconds before sending data at a rate of 500 =
bytes/sec.
If I understand your model correctly we would cancel the request anytime =
if the client
falls below 500 bytes/sec. So if it does start only with 200 bytes/sec =
we would cancel
it immediately.

Regards

R=FCdiger