Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
If a client sends ALPN information in its hello, it certainly can expect an answer from the server. Since in absence of any other modules, the httpd will do „http/1.1“, I think that is a reasonable response. For clients that do not sent ALPN, any possible answer from the server will not be relevant for them. And I would be surprised if a client gets confused by that. If it uses openssl, it will probably not have registered own callbacks and thus never see the server answer. As to the "check for sc->server->ssl_alpn_pref->nelts“ that is very much depending on the order of hooks. In the case of mod_h2, registering for alpn happens in pre connection hooks and those run *after* mod_ssl pre_connection hook, I am pretty sure. //Stefan > Am 03.06.2015 um 14:52 schrieb Yann Ylavic <ylavic....@gmail.com>: > > I wonder if registering the ssl_callback_alpn_select callback > inconditionally could break some clients. > Are those (ALPN ready) always negociate "http/1.1"? > > Otherwise we could check for sc->server->ssl_alpn_pref->nelts > 0 (or > a dedicated SSLAlpnEnable) beforing using > SSL_CTX_set_alpn_select_cb(). > In that case mod_h2 would not work out of the box, needing some > administration on the httpd side. > > > On Wed, Jun 3, 2015 at 12:56 PM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and >> openssl 1.0.2. All my tests ran fine. >> >> //Stefan >> >>> Am 02.06.2015 um 16:56 schrieb Eric Covener <cove...@gmail.com>: >>> >>> Can you test the latest rev of the backport candidate? >>> >>> http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch >>> >>> >>> >>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing >>> <stefan.eiss...@greenbytes.de> wrote: >>> >>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <httpd-dev.2...@velox.ch>: >>>> >>>> On 22.04.2015 18:54, Jim Jagielski wrote: >>>>>> For me the time seems right to rip NPN out of trunk and only backport >>>>>> the ALPN code to 2.4. >>>>>> >>>>> >>>>> I'd be +1 for that. >>>> >>>> So, to get one step further, and since there were no explicit objections >>>> to removing NPN support so far (or arguments for keeping it, FWIW), I >>>> went ahead and took a stab at this with r1676004. >>>> >>>> Only tested in terms of "compiles both w/ and w/o HAVE_TLS_ALPN", so it >>>> certainly needs more eyes before a backport proposal could be made. >>>> There's also a "TODO: we should have a mod_ssl configuration parameter" >>>> in ssl_engine_kernel.c which I'm unsure to what it refers. >>> >>> The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It >>> can be removed. >>> >>> I diff’ed the current mod_ssl against the 2.4 branch, removed everything >>> but he ALPN changes and made a patch for my sandbox. This works on my OS X >>> with mod_h2. My Ubuntu sandbox is still resisting as some test clients >>> still link the system ssl which only speaks NPN (or link against a >>> lib_event that links against the system openssl). It’s a mess. >>> >>> Stefan >>> >>>> >>>> Kaspar >>> >>> <green/>bytes GmbH >>> Hafenweg 16, 48155 Münster, Germany >>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 >>> >>> >>> >> >> <green/>bytes GmbH >> Hafenweg 16, 48155 Münster, Germany >> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 >> >> >> <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
