> Am 05.06.2015 um 01:37 schrieb Yann Ylavic <ylavic....@gmail.com>:
> On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding <field...@gbiv.com> wrote:
>> Hence, we might need a configurable way to ignore a client's ALPN, though I 
>> doubt that
>> "SSLalpn off" is the right way to express that.  Likewise, neither is 
>> SSLAlpnPreference.
>> The server protocol(s) preference should be independent of the 
>> session/connection protocol.
>> Our internal configuration and use of ALPN should be based on the overall 
>> configuration, not a
>> configuration specific to the SSL code.  Many configurations won't include 
>> ALPN.
> Maybe we can reuse the Protocol directive then...

Something like the one below maybe. But this is 2.6/3.0 music. What do we do 
for 2.4?

cheers, Stefan
# Listen directives define which transport protocols are active
Listen 443
Listen 1234 ssh

# Protocols lists the ALPN identifiers allowed on connections in preferred order
# ProtocolTransports defaults to the union of transports the server listens to
Protocols h2 spdy/3.1 http/1.1
ProtocolTransports tls ssh clear        

# vhosts may limit this down or change order (but not extend it?)
<vhost *>
  ServerName test1.example.org
  Protocols h2 http/1.1
  ProtocolTransports tls
<vhost *>
  ServerName test2.example.org
  Protocols *
  ProtocolTransports ssh

Modules with protocol support need to register the ALPN ids plus a callback at 
core where they become available at the base server? Callbacks  are invoked for 
selected protocol with selected protocol id.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Reply via email to