On Thu, Nov 20, 2014 at 9:57 AM, Yann Ylavic <[email protected]> wrote: > On Wed, Nov 19, 2014 at 1:13 PM, Eric Covener <[email protected]> wrote: >> On Wed, Nov 19, 2014 at 4:47 AM, Yann Ylavic <[email protected]> wrote: >>> Errr, this is in 2.2.x/STATUS only (not 2.4.x). >>> Is it already proposed/backported to 2.4.x (I can't find the commit)? >> >> I diff'ed trunk and 2.4 and It seems to be absent. >> >> I don't have the best handle on this, but if we're about to go down >> into a blocking read, wouldn't we want to check the time left and >> reduce the timeout? > > Yes, good point. > > Maybe this way then? > > Index: modules/filters/mod_reqtimeout.c > =================================================================== > --- modules/filters/mod_reqtimeout.c (revision 1640032) > +++ modules/filters/mod_reqtimeout.c (working copy) > @@ -311,7 +311,12 @@ static apr_status_t reqtimeout_filter(ap_filter_t > else { > /* mode != AP_MODE_GETLINE */ > rv = ap_get_brigade(f->next, bb, mode, block, readbytes); > - if (ccfg->min_rate > 0 && rv == APR_SUCCESS) { > + /* Don't extend the timeout in speculative mode, wait for > + * the real (relevant) bytes to be asked later, within the > + * currently alloted time. > + */ > + if (ccfg->min_rate > 0 && rv == APR_SUCCESS > + && mode != AP_MODE_SPECULATIVE) { > extend_timeout(ccfg, bb); > } > }
Looks good
