You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ji...@apache.org on 2013/03/19 14:56:30 UTC
svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
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;
+ }
+
if (ccfg->in_keep_alive) {
/* For this read, the normal keep-alive timeout must be used */
ccfg->in_keep_alive = 0;
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 19, 2013, at 1:50 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 19 Mar 2013, at 7:44 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Agreed... The conn_rec includes a bunch of HTTP related fields
>> which could serve as such, but the main issue, I think, is
>> that websockets starts off as HTTP and then changes, so the
>> initial conn_rec info is HTTP, it's just that after the
>> Upgrade, it isn't. So at that point, it's hard to change.
>>
>> The other way to handle this, I *think*, and keep mod_reqtimeout.c
>> virgin, is, in the websocket module, use ap_get_input_filter_handle()
>> to get "reqtimeout" and then remove it directly in the websocket module.
>>
>> It's not automagical, but it prevents monkeying w/ mod_reqtimeout.
>
> Could we add a note perhaps that indicated the protocol that is currently in use for the connection? Typically it would be "HTTP/1.1", but after an Upgrade it would be whatever it is being upgraded to (perhaps "CONNECTION", or "STARTTLS", or "WEBSOCKET"?).
Makes sense... I also think we need to look at
the idea of a sub-connections (similar to sub-requests)
(as was suggested at the mod_spdy preso @ ACNA13).
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Mar 2013, at 7:44 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Agreed... The conn_rec includes a bunch of HTTP related fields
> which could serve as such, but the main issue, I think, is
> that websockets starts off as HTTP and then changes, so the
> initial conn_rec info is HTTP, it's just that after the
> Upgrade, it isn't. So at that point, it's hard to change.
>
> The other way to handle this, I *think*, and keep mod_reqtimeout.c
> virgin, is, in the websocket module, use ap_get_input_filter_handle()
> to get "reqtimeout" and then remove it directly in the websocket module.
>
> It's not automagical, but it prevents monkeying w/ mod_reqtimeout.
Could we add a note perhaps that indicated the protocol that is currently in use for the connection? Typically it would be "HTTP/1.1", but after an Upgrade it would be whatever it is being upgraded to (perhaps "CONNECTION", or "STARTTLS", or "WEBSOCKET"?).
Regards,
Graham
--
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 19, 2013, at 1:15 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 19 Mar 2013, at 7:09 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> I've added bypassing and removing... for flexibility.
>
> Is there a generic way for modules to figure out for themselves whether they should be caring about a particular request or connection?
>
> In other words, if reqtimeout had a way to say "is this an HTTP request?" and if the answer is no, step away?
>
> In the case where the protocol is upgraded, or is in some way made to be no longer HTTP, a module like reqtimeout can step out of the way automagically, and modules don't need explicit knowledge about one another.
Agreed... The conn_rec includes a bunch of HTTP related fields
which could serve as such, but the main issue, I think, is
that websockets starts off as HTTP and then changes, so the
initial conn_rec info is HTTP, it's just that after the
Upgrade, it isn't. So at that point, it's hard to change.
The other way to handle this, I *think*, and keep mod_reqtimeout.c
virgin, is, in the websocket module, use ap_get_input_filter_handle()
to get "reqtimeout" and then remove it directly in the websocket module.
It's not automagical, but it prevents monkeying w/ mod_reqtimeout.
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Graham Leggett <mi...@sharp.fm>.
On 19 Mar 2013, at 7:09 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> I've added bypassing and removing... for flexibility.
Is there a generic way for modules to figure out for themselves whether they should be caring about a particular request or connection?
In other words, if reqtimeout had a way to say "is this an HTTP request?" and if the answer is no, step away?
In the case where the protocol is upgraded, or is in some way made to be no longer HTTP, a module like reqtimeout can step out of the way automagically, and modules don't need explicit knowledge about one another.
Regards,
Graham
--
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
I've added bypassing and removing... for flexibility.
On Mar 19, 2013, at 12:52 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> Jeff Trawick wrote:
>> On Tue, Mar 19, 2013 at 9:56 AM, <ji...@apache.org> 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
>
>
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Ruediger Pluem <rp...@apache.org>.
Jeff Trawick wrote:
> On Tue, Mar 19, 2013 at 9:56 AM, <ji...@apache.org> 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
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
Oops... yeah, did this too fast ;)
As far as which makes the most sense, (call-by-call
or forever), both would be best...
On Mar 19, 2013, at 12:16 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Mar 19, 2013 at 9:56 AM, <ji...@apache.org> 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)
>
>> + }
>> +
>> if (ccfg->in_keep_alive) {
>> /* For this read, the normal keep-alive timeout must be used */
>> ccfg->in_keep_alive = 0;
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
Re: svn commit: r1458284 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 19, 2013 at 9:56 AM, <ji...@apache.org> 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)
> + }
> +
> if (ccfg->in_keep_alive) {
> /* For this read, the normal keep-alive timeout must be used */
> ccfg->in_keep_alive = 0;
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/