httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_ssl: why do we flush on EOS in ssl_io_filter_output()?
Date Mon, 04 Nov 2013 14:03:28 GMT
On 28 Oct 2013, at 6:23 PM, Eric Covener <covener@gmail.com> wrote:

>>> It would seem at the very least in order for any kind of write completion to
be possible we would need to stop mod_ssl from trying to flush on EOS. Is there a specific
problem that mod_ssl tries to solve by doing this?
>> 
>> If you go back to e.g. r91413 and look at the entire file, it seems
>> that the EOS used to flush out some data buffered in openssl:
> 
> Sorry, stray gmail keystrongs, meant to include
> 
> ssl_io_filter_Output()
> ...
>    APR_BRIGADE_FOREACH(bucket, bb) {
>        const char *data;
>        apr_size_t len, n;
> 
>        if (APR_BUCKET_IS_EOS(bucket)) {
>            if ((ret = churn_output(ctx)) != APR_SUCCESS) {
> 
> 
> churn_output()
> ...
>  if (BIO_pending(ctx->pbioWrite)) {
>   ... flush

Looking at the code today, on EOS we call bio_filter_out_flush(), which creates a flush bucket
and then gives it to bio_filter_out_pass(), which just ap_pass_brigade()'s it down to the
network filter. I am not seeing any openssl functionality being called to flush any openssl
state of any kind.

At the very least flush-on-eos is harmful, as it breaks write completion by definition, so
it looks like this behaviour needs to go.

Looking a little bit deeper, we find the following:

- The event MPM seems to want to perform write completion on the very last filter in the chain
only, which seems completely arbitrary - why should another filter (like mod_ssl) be prevented
from running within write completion? Doesn't make sense to me. Ideally we need to teach the
event MPM to run write completion on a class of filters, such as AP_FTYPE_NETWORK, and make
it a rule that network filters must be aware of and are not allowed to block async MPMs. Given
that in theory there is only one AP_FTYPE_NETWORK filter (to my knowledge), this should be
backportable to v2.4.
- mod_ssl defines itself as "AP_FTYPE_CONNECTION + 5", which looks to me like mod_ssl really
wants to be a network filter, not a connection filter. If we were to teach the event MPM above
to trigger network filters, I propose that mod_ssl becomes a network filter following the
"not allowed to block async MPMs" rule (which it should do already anyway).

Thoughts?

Regards,
Graham
--


Mime
View raw message