Ok, in ssl_engine_io.c, lines 1426+ I see a hint: /* XXX: we could actually move ssl_io_filter_handshake to an * ap_hook_process_connection but would still need to call it for * AP_MODE_INIT for protocols that may upgrade the connection * rather than have SSLEngine On configured. */ if ((status = ssl_io_filter_handshake(inctx->filter_ctx)) != APR_SUCCESS) { return ssl_io_filter_error(f, bb, status); }
The handshake handling gets triggered on a filter, so it all happens on READs (or WRITEs), which explains why connection hooks do not see it. This is quite some code which looks like we do not want to touch for a "quick fix". Also, there is no quick fix inside mod_http2 as before handshake, the SNI might also not be there yet, thus the vhost cannot be determined. etc. For the current release, I think we should leave it as it is and advise that current mod_http2 is incompatible with things like nntp. For the next release, I'd like the server to perform the handshake at a defined time, so other modules can rely on protocols being selected and correct vhost being known before the first read/write. //Stefan > Am 11.10.2015 um 19:30 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: > > What is the penalty of invoking SSL_do_handshake(ssl) on the server side for > a new connection? We do this on renegotiate and upgrade cases... > >> Am 11.10.2015 um 19:23 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: >> >> >>> Am 11.10.2015 um 19:19 schrieb Rainer Jung <rainer.j...@kippdata.de>: >>> >>> Am 11.10.2015 um 19:08 schrieb Yann Ylavic: >>>> On Sun, Oct 11, 2015 at 7:00 PM, Stefan Eissing >>>> <stefan.eiss...@greenbytes.de> wrote: >>>>> Ok, analyzed the code. Here is what seems to be happening: >>>>> >>>>> - mod_http2, in the connection hook, does a blocking, speculative read to >>>>> a) make sure the ALPN has been triggered >>>>> b) check for the magic 24 bytes h2 preface in case H2Direct is on >>>>> This works fine for HTTP/1.1 or protocols where the client starts sending >>>>> bytes right away. >>>>> If the client waits for something from the server first, it gives a >>>>> timeout. This seems to be the NNTP case. >>>> >>>> Does it make any sense to enable h2 on NNTP? >>> >>> For now I disabled the nntp over ssl test when mod_http2 is loaded >>> (disabled in the test file) so that the test suite does not hang. >>> >>> I guess we don't want to test h2 and NNTP on the same requests, but it >>> would be ideal, if the modules would not disturb each other, if they serve >>> different vhosts in the same Apache. If that's not possible and doesn't >>> actually indicate a bigger problem, I'm personally fine with that >>> incompatibility with protocols that show "server sends first" behavior. >> >> Agreed. What we need is a way to make sure that any ALPN handling is done >> for later connection hooks. Then mod_http2 will only need to sniff when >> H2Direct is enabled. >