httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: r1470679, async write completion, non blocking writes, and mod_ssl
Date Thu, 15 Aug 2013 08:56:21 GMT
Am Donnerstag, 15. August 2013, 02:36:25 schrieb Graham Leggett:
> On 14 Aug 2013, at 22:43, Stefan Fritsch <sf@sfritsch.de> wrote:
> > Unfortunately, I haven't been able to trigger the new code path in
> > mod_ssl being actually used. Do you have any example
> > setup/situation, where the SSL_ERROR_WANT_READ case is actually
> > hit?
> 
> I suspect you have misunderstood the problem the patch tries to fix.
> 
> SSL negotiation and renegotiation involve both reads and writes, and
> these reads might be performed inside SSL_write, and these writes
> might be performed inside SSL_read.
> 
> When OpenSSL is switched to async mode, it returns two distinct
> codes to signify that the sense of the poll must be changed.
> Historically the core was oblivious to this requirement, and
> happily tried to poll for read when OpenSSL had asked for
> permission to write. With nothing to be read, the connection would
> hang indefinitely.
> 
> This patch fixed two things. It taught the core how to respect the
> sense requested by OpenSSL, and it removed the hack that forced SSL
> connections to be sync only.

I have understood that. But I would have liked to see the sense code 
in action, but failed to trigger it. At least t/ssl/pr12355.t in the 
test suite uses renegotiation, and I have also tried client initiated 
renegotiation (after removing the code that rejects it), but neither 
causes httpd to use the new code paths. So, do you have a test setup 
where the new code paths are actually used?


Mime
View raw message