httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: mod_reqtimeout backport
Date Sat, 16 Jan 2010 20:10:18 GMT
On Wed, 13 Jan 2010, Dan Poirier wrote:
>>> 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.
> Yes, my proposal probably simplifies things too much.  We could allow
> some time for things to get going.  Maybe not start enforcing the
> minimum rate until after some number of seconds, with a reasonable
> default but it could be configured:
>  HeaderStartupTime: time in seconds before the specified HeaderMinRate
>  starts being enforced.  Default = 10 seconds.
> I'm not thrilled with that though, it's inelegant.

In any case, we need at least three values to completely define the 
behaviour. IIRC I chose the initial timeout/maximum timeout over the 
startup time/maximum timeout approach because it was easier to implement. 
I still think it's ok, given that for normal configurations, there is not 
much difference. But the "headerinit" keyword is just a bit too cryptic 
for my taste.

Do you agree that using RequestReadTimeout instead of RequestTimeout and 
using a single keyword with a timeout range is more descriptive than the 
current syntax?

View raw message