On 06/03/2015 03:43 PM, Stefan Eissing wrote:
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.
I'm not sure if that's the same case, but Red Hat actually has open bug
report for the old 2.4.x NPN code (right now reverted in 2.4.x) about
NPN extensions being sent even they have not been configured.
I think last time I've checked, the httpd trunk ALPN code did something
similar (returned http/1.1 when no other modules have been configured).
The reasoning in that Red Hat bug report is that there should be a way
how to stop this behavior because of compliance with some security
standards.
I just want to point out that there might be some users who care about this.
Regards,
Jan Kaluza
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
