> -----Ursprüngliche Nachricht-----
> Von: Yann Ylavic [mailto:ylavic....@gmail.com]
> Gesendet: Dienstag, 6. Oktober 2015 18:18
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1706275 -
> /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> 
> On Tue, Oct 6, 2015 at 6:00 PM, Yann Ylavic <ylavic....@gmail.com>
> wrote:
> > On Tue, Oct 6, 2015 at 5:44 PM, Joe Orton <jor...@redhat.com> wrote:
> >>
> >> Hence In the server case, it seems reasonable to rely on BIO_flush()
> >> being called at the "right" times during the handshake.  Modulo the
> odd
> >> bug!
> >>
> >> But ssl/s3_clnt.c is not following that coding style at all, and it
> only
> >> does a flush after completing the handshake.  So I'd say the right
> thing
> >> here is to FLUSH after every packet which comes through the write BIO
> >> when the SSL state machine is in the middle of a "connect", i.e.
> >> handshake as client.
> >>
> >> tl;dr: I think Yann's patch should be right if the test is switched
> from
> >> "always flush if !SSL_is_init_finished(ssl)" to "always flush if
> >> SSL_in_connect_init(ssl)"???
> >
> > Yes, I came to the same conclusion, but decided to use
> > SSL_is_init_finished(ssl) anyway because for the server case it seems
> > that openssl uses it own buffering mechanism to avoid writing small
> > chunks (after the client-hello is received), so possibly we could rely
> > on it (this also simplifies the logic).
> 
> Also it seems that for the SSL_ST_RENEGOTIATE state in ssl3_accept(),
> buffering is disabled by openssl (at least in 1.0.2d).
> SSL_is_init_finished(ssl) should catch this case too...

I am confused now. I understood that the state machine for the server case is 
fine. Hence that it flushes automatically where needed. So we only should and 
need to take care of the client case.
How does using !SSL_is_init_finished(ssl) simplifies the logic?


Regards

Rüdiger

Reply via email to