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
>
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
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
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
> 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
> 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
>>
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.
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
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
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
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
>>
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
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
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
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
15 matches
Mail list logo