"Plüm, Rüdiger, VF-Group" <[email protected]> writes:
>> -----Original Message----- >> From: news [mailto:[email protected]] On Behalf Of Dan Poirier >> 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.
