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 <[email protected]>:
>
> 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 <[email protected]>:
>>
>>
>>> Am 11.10.2015 um 19:19 schrieb Rainer Jung <[email protected]>:
>>>
>>> Am 11.10.2015 um 19:08 schrieb Yann Ylavic:
>>>> On Sun, Oct 11, 2015 at 7:00 PM, Stefan Eissing
>>>> <[email protected]> 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.
>
