httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: BUFF question: sucking data without consuming
Date Mon, 26 Jul 1999 07:03:27 GMT

In article <> you wrote:

> Yeah, why can't you just keep a "low water mark" or something in the BIO? 
> You need to handle renegotiations anywhere, and you need to handle
> bi-directional protocols... apache isn't the only app using openssl... or
> maybe I completely misunderstand the problem.
>> To be honest, this sounds like a bug in openssl... renegotiation is a
>> transport layer issue, the application layer shouldn't be aware of it
>> except perhaps via a cert checking hook, but certainly not as an odd bump
>> in the stream.  For example, suppose the protocol you were wrapping was
>> IMAP, wouldn't you require this bsuck all over the place?
>> > For SSL renegotiation situations where POST methods are involved we have
>> > discovered that we need a way to transfer the pending POST data from OpenSSL's
>> > underlaying input buffer (a BIO) to Apache's buffer (a BUFF), but _without_
>> > consuming it through the ap_gets/ap_read and friends functions.
>> > 
>> > The intent is that this way the SSL BIO is empty and the renegotiation can be
>> > successfully done while after the renegotiation Apache's upper layer can
>> > resume the POST handling (in mod_cgi, etc.).
>> > 
>> > So the question is: Is there an easy way to read the POST data into Apache's
>> > BUFF without consuming it. Or have we write an own ap_bsuck() function which
>> > does the trick? If yes, can it be based on existing ap_bxxx() functions or
>> > should it do the stuff directly?

No, you're not misunderstanding the problem, of course. I'm myself still not
convinced what the _CORRECT_ solution is. I'm currently poking around to find
an easy solutions and I thought some ap_bsuck() function could solve it. But
you're right, it might be more a problem with OpenSSL's SSL BIO which seems to
not allow renegotiations while there is still pending data.  Hmmm...  at least
yesterday I've looked over our complete buff.c and it seems a ap_bsuck()
cannot be done in a general way, at least not when there is more pending
receive data than 4KB. So, this ap_bsuck() idea we can forget. Next I'll look
inside OpenSSL's SSL BIO...
                                       Ralf S. Engelschall

View raw message