httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: 2.4.17 test failure for mod_nntp_like_ssl when mod_http2 is loaded
Date Mon, 12 Oct 2015 13:36:53 GMT
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 <minfrin@sharp.fm>:
> 
> On 11 Oct 2015, at 7:00 PM, Stefan Eissing <stefan.eissing@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
> —
> 


Mime
View raw message