I've added bypassing and removing... for flexibility. On Mar 19, 2013, at 12:52 PM, Ruediger Pluem <[email protected]> wrote:
> > > Jeff Trawick wrote: >> On Tue, Mar 19, 2013 at 9:56 AM, <[email protected]> wrote: >>> Author: jim >>> Date: Tue Mar 19 13:56:29 2013 >>> New Revision: 1458284 >>> >>> URL: http://svn.apache.org/r1458284 >>> Log: >>> Allow modules to pro-actively bypass the reqtimeout filter (by connection) >>> >>> Modified: >>> httpd/httpd/trunk/modules/filters/mod_reqtimeout.c >>> >>> Modified: httpd/httpd/trunk/modules/filters/mod_reqtimeout.c >>> URL: >>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reqtimeout.c?rev=1458284&r1=1458283&r2=1458284&view=diff >>> ============================================================================== >>> --- httpd/httpd/trunk/modules/filters/mod_reqtimeout.c (original) >>> +++ httpd/httpd/trunk/modules/filters/mod_reqtimeout.c Tue Mar 19 13:56:29 >>> 2013 >>> @@ -177,6 +177,11 @@ static apr_status_t reqtimeout_filter(ap >>> apr_interval_time_t saved_sock_timeout = UNSET; >>> reqtimeout_con_cfg *ccfg = f->ctx; >>> >>> + /* connections can bypass the filter even if configured */ >>> + if (apr_table_get(f->c->notes, "bypass-reqtimeout")) { >>> + return APR_SUCCESS; >> >> a no-op input filter returns apr_get_brigade(same_params) >> >> is the idea that this can be tweaked call-by-call, or is it >> once-on-bypass-forever, or ??? (I'm thinking about how cheap a check >> of a field in the context should be) > > And in case it should be for the whole connection (which would be my > understanding) > doesn't it make sense to remove the filter completely from the chain? > > Regards > > Rüdiger > >
