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. 



> 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

Reply via email to