> -----Original Message----- > From: news [mailto:[email protected]] On Behalf Of Dan Poirier > Sent: Mittwoch, 13. Januar 2010 15:28 > To: [email protected] > Subject: Re: mod_reqtimeout backport > > Stefan Fritsch <[email protected]> writes: > > > I am not particularly happy about the syntax, yet. I just > had the idea > > to have one keyword xxx that can optionally accept a range, > instead of > > two keywords xxxinit and xxxmax: > > > > Header=30 > > Body=5-50 BodyMinRate=500 > > > > or > > > > Header=5-20,minrate=500 > > Body=5-50,minrate=500 > > > > but the combination > > > > Header=5,minrate=1000 > > > > is less clear. Maybe make the '-' mandatory in this case: > > > > Header=5-,minrate=1000 > > > > Any opinions or better ideas? > > > > One could also rename RequestTimeout into > RequestReadTimeout if that > > makes it easier to understand. > > We might simplify the model by not exposing the internal extending of > the timeout. Just let the admin specify an overall max time, > a minimum > rate, or both: > > HeaderTimeout: Maximum seconds to read the entire header. > > HeaderMinRate: Minimum rate (bytes/second) allowed when reading the > request header. If the rate drops below this, the request is timed > out. > > 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üdiger
