Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 07 Oct 2015, at 7:46 PM, Plüm, Rüdiger, Vodafone Group wrote: > I guess we are talking of different things. During the initial handshake > (client or server) we never hand back > control to the event part of the MPM. We never use ssl_filter_write and >

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Wed, Oct 07, 2015 at 01:35:38AM +0200, Yann Ylavic wrote: > For the server case, openssl will use its own buffering mechanism > during the handshake "so that the output is sent in a way that TCP > likes", according to the comment in the code, so we shouldn't be > flushing small chunks. > Yet

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 07 Oct 2015, at 10:04 AM, Joe Orton wrote: > That's really interesting. That extra buffering BIO makes sense if > OpenSSL is writing to the socket descriptor directly, as with pre-2.x > mod_ssl, but doesn't really make sense with 2.x mod_ssl, since the core > output

AW: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

> -Ursprüngliche Nachricht- > Von: Graham Leggett [mailto:minf...@sharp.fm] > Gesendet: Mittwoch, 7. Oktober 2015 17:59 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1706275 - > /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c > > On 07 Oct 2015, at 5

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 07 Oct 2015, at 5:53 PM, Jim Jagielski wrote: >> As I understand we’re using openssl in non blocking mode, which means that >> openssl will ask us permission before attempting any read or write. >> >> The core will then in turn either read or write as requested by openssl

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

> On Oct 7, 2015, at 11:59 AM, Graham Leggett wrote: > > On 07 Oct 2015, at 5:53 PM, Jim Jagielski wrote: > >>> As I understand we’re using openssl in non blocking mode, which means that >>> openssl will ask us permission before attempting any read or

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

> On Oct 7, 2015, at 5:17 AM, Graham Leggett wrote: > > On 07 Oct 2015, at 10:04 AM, Joe Orton wrote: > >> That's really interesting. That extra buffering BIO makes sense if >> OpenSSL is writing to the socket descriptor directly, as with pre-2.x >>

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Wed, Oct 7, 2015 at 5:59 PM, Graham Leggett wrote: > On 07 Oct 2015, at 5:53 PM, Jim Jagielski wrote: > >>> As I understand we’re using openssl in non blocking mode, which means that >>> openssl will ask us permission before attempting any read or write.

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 06, 2015 at 02:37:32PM +, Plüm, Rüdiger, Vodafone Group wrote: > The drawback is that it will flush every time the handshake writes. > The handshake may write multiple times before it wants to read. > So the current approach probably causes bigger amounts of data sent > across the

AW: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

> -Ursprüngliche Nachricht- > Von: Yann Ylavic [mailto:ylavic@gmail.com] > Gesendet: Dienstag, 6. Oktober 2015 16:06 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1706275 - > /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c > > On Thu, Oct 1, 2015 at

AW: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

> -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

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 6, 2015 at 8:41 PM, Plüm, Rüdiger, Vodafone Group wrote: > > > 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

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Thu, Oct 1, 2015 at 8:22 PM, Ruediger Pluem wrote: > > The issue is that openssl during the connect handshake to a clieent does not > tell httpd to flush. Hence the CLIENT_HELLO > remains in the core output filter buffer and openssl waits for the > SERVER_HELLO from the

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 6, 2015 at 6:00 PM, Yann Ylavic wrote: > On Tue, Oct 6, 2015 at 5:44 PM, Joe Orton 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 >>

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On Tue, Oct 6, 2015 at 5:44 PM, Joe Orton 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

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 01 Oct 2015, at 8:22 PM, Ruediger Pluem wrote: > The issue is that openssl during the connect handshake to a clieent does not > tell httpd to flush. Hence the CLIENT_HELLO > remains in the core output filter buffer and openssl waits for the > SERVER_HELLO from the remote

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 01 Oct 2015, at 5:43 PM, yla...@apache.org wrote: > URL: http://svn.apache.org/viewvc?rev=1706275=rev > Log: > mod_ssl: follow up to r1705823. > We still need to flush in the middle of a SSL/TLS handshake. Can you confirm why the flushing is necessary? In theory mod_ssl should be switching

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

On 10/01/2015 06:59 PM, Graham Leggett wrote: > On 01 Oct 2015, at 5:43 PM, yla...@apache.org wrote: > >> URL: http://svn.apache.org/viewvc?rev=1706275=rev >> Log: >> mod_ssl: follow up to r1705823. >> We still need to flush in the middle of a SSL/TLS handshake. > > Can you confirm why the