mod_ssl update...

[Justin Erenkrantz <je...@ebuilt.com>]

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