httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <>
Subject Re: What is a "clogging" input filter?
Date Fri, 19 Apr 2013 16:38:46 GMT
On Fri, Apr 19, 2013 at 11:14 AM, Graham Leggett <> wrote:
> Hi all,
> Currently mod_ssl doesn't work with the event MPM, as per the following code:
>     if (c->clogging_input_filters && !c->aborted) {
>         /* Since we have an input filter which 'cloggs' the input stream,
>          * like mod_ssl, lets just do the normal read from input filters,
>          * like the Worker MPM does.
>          */
>         apr_atomic_inc32(&clogged_count);
>         ap_run_process_connection(c);
>         if (cs->pub.state != CONN_STATE_SUSPENDED) {
>             cs->pub.state = CONN_STATE_LINGER;
>         }
>         apr_atomic_dec32(&clogged_count);
>     }
> Can anyone explain what it means exactly to clog the input stream?
> Am I right in understanding that openssl reads ahead, and therefore there may not be
data for reading when we get to apr_pollset_poll()?
> Or is this instead to do with openssl returning SSL_ERROR_WANT_READ during SSL_write?
(and vice versa)?

I have this starred response from Paul Querna in my gmail:

It means the filter buffers in such a way that it might have data
inside it, but a poll() on the socket will never return active when it
has data ready.  It also has to do with filters that change the
read/write flow -- we currently don't have a way for an output filter
for example to say "come back to me when there is data available to
READ".  This is specifically the mod_ssl problem, because of the SSL
protocol, you often need to do a write before you can read, or vice

> What would it take to make mod_ssl a non-clogging filter?

Basically needs two things:
1) Never buffer data inside ssl (feasible I believe)
2) Create a new way for a filter deep inside the chain to indicate we
need to wait for a read/write ability on a socket -- this
fundamentally is why a Serf bucket model is better than our chained
filters.  An alternative  approach would be changing the flow so
filters don't directly call the next filter, putting the core back in
control of filter flow, but this is still a non-trivial project.

Eric Covener

View raw message