Yeah, mod_ssl's filtering model just isn't meshing well with the rewrite to the input filtering. Since I think most of us on the list have come to the consensus that what I committed is closer to the "right thing" (whatever that pie-in-the-sky may be), I think we need to consider altering mod_ssl's filtering model to fit with our new expectations.
I think it's doable, but it isn't going to be a trivial one-line patch. I'll quote RSE here from the top of the ssl_engine_io.c: /* XXX THIS STUFF NEEDS A MAJOR CLEANUP -RSE XXX */ So, I'm obviously not the first one to think this and that was before the input filters change forced this issue. =) Anyway, I see that the input and output filters are handled by one function - churn. Is that dictated by the mechanics of OpenSSL? Can we separate input and output entirely or do we need to have them coexist like they are now? Basically, the root problem is that mod_ssl's input filtering routines are expecting to get the socket back with the -1 length and do a FOREACH until it is exhausted. That's not how it works anymore, so mod_ssl is going to be broken until we teach it how to properly handle reading from the socket in little chunks (via ap_get_brigade via CORE_IN). But, I think we may have to jettison CORE_IN when mod_ssl is used because we need to get enough data to renegotiate, etc, etc, etc. I also don't think OpenSSL will like the idea of renegotiating via buckets. =) So, I think we have to teach mod_ssl's input filter to standalone without the help of the core. That means (I think) that we could use the SSL_* (i.e. SSL_read) functions when reading from the socket rather than ap_get_brigade/BIO_*. Can we intermix calls to BIO_* and SSL_*? Are they separate? When do we want to use BIO_* and not SSL_*? There is just a lot of stuff here. And, I think Ralf nailed it on the head. =) I'm not sure that I see a simple way around this, but I'm open to suggestions. Thoughts? -- justin
