With r1708107 I committed the following changes to /trunk: mod_ssl: - calling ap_switch_protocol directly after ap_select protocol from inside the SSL ALPN callback. Error in switching will result in a TLS error which seems correct. This makes sure that after the ALPN has been triggered, the protocol switch is in place. - alpn_finished check in ssl_engine_io could be removed then. Less flags and #ifdefs overall...
mod_http2: - connection hook triggers handshake by reading in AP_MODE_INIT 0 bytes - connection hook only every tries to do a blocking read if H2Direct is enabled and the connection is still on protocol "http/1.1" - the default for H2Direct has been changed to "off" for all kinds of connections - documentation xml updated - ht_task_input passes AP_MODE_INIT calls on to chained filters I did not test the nntp case (can I? how?), but this should address the issue. Observations: - The AP_MODE_INIT read should be done in a connection hook of mod_ssl itself. Other modules like mod_http2 should not care about that. - With SNI, the selected virtual host really is a property of the connection. It would be good to get access to it from other modules *without* having a request_rec Thanks for all the good suggestiongs from Yann and Rüdiger! //Stefan > Am 12.10.2015 um 14:10 schrieb Graham Leggett <minf...@sharp.fm>: > > On 11 Oct 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 > > Looking at the code inside the event MPM that calls > ap_run_process_connection(), it looks like you can just do a non blocking > read, and if you haven’t received enough bytes, return DECLINED and expect to > be called again. > > This presupposes that other connection filters aren’t trying to be > excessively cleaver by stealing your connection away from you and then > responding to your data (for example by error-ing out), which they may do by > doing blocking reads. > > Regards, > Graham > — >
