I think we need to clarify some things: 1. ALPN is initiated by the client. When a client does not send ALPN as part of client helo, the SSL alpn callbacks are not invoked and the server does not send any ALPN information back. This is different from NPN.
2. SSLAlpnPreference is intended as the final word to make a choice when either one ALPN callback proposes many protocols or of several callbacks propose protocols. So, when mod_spdy and mod_h2 are active *and* the client claims to support spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and sent to the client. This was not necessary with NPN as in that SSL extension the client was making the choice. 3. Independent of the client proposal, as I read the spec, the server is free to chose any protocol identifier it desires. This might result in the client closing the connection. So, if the client uses ALPN and the server does not want/cannot do/is configured not to support any of the clients proposals, httpd can always send back „http/1.1“ since this is what it always supports. In this light, and correct me if I’m wrong, I see no benefit and only potential harm by introducing a „SSLALpn on|off“ configuration directive. I think the current implementation covers all use cases and if one is missing, please point out the scenario. As with the register once or on every connection optimization, yes, there might be some performance to gain. But I think it is not so straightforward to implement this, as not only the address and port influences this but also the SNI that gets send in the client helo. So, one would have at least to verify that registering an ALPN callback *after* the connection is open and SNI has been received has any effect. cheers, Stefan > Am 04.06.2015 um 14:52 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener <cove...@gmail.com> wrote: >>> >>> >>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic <ylavic....@gmail.com> wrote: >>>> >>>> I think what makes the thing a bit awkward is that the >>>> negotiable/preferred ALNP identifiers (protocols) is configurable in >>>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded). >>>> The former is only a hint while the latter is the real proposal to the >>>> client (with the fall back to "http/1.1"). >>>> >>>> Maybe it would be cleaner to let the modules register the ALPN >>>> identifiers (at configure time, with another optional function), and >>>> get rid of SSLAlpnPreference on mod_ssl side. >>>> If no identifier is registered, mod_ssl won't register the ALPN >>>> callback either, so that httpd continues to work without ALPN when not >>>> needed. >>>> >>> I think we need SSLAlpnPreference any time modules register ALPN protocols, >>> otherwise the admin has no control over whih is negotiated. I don't think >>> we should rip it out. >> >> OK, so it should probably be renammed SSLAlpnIDs or similar, and be >> more than just a hint when configured (i.e. refuse connection if no >> client ALPN ID matches). > > I meant fall back to "http/1.1" still, not refuse the connection. <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
