httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: ALPN patch comments
Date Wed, 03 Jun 2015 13:43:06 GMT
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.


> Am 03.06.2015 um 14:52 schrieb Yann Ylavic <>:
> 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
> <> 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 <>:
>>> Can you test the latest rev of the backport candidate?
>>> On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing <>
>>>> Am 25.04.2015 um 11:47 schrieb Kaspar Brand <>:
>>>> 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

View raw message