On 28 Oct 2013, at 6:23 PM, Eric Covener <cove...@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
--
