> 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> <vhost *> ServerName test2.example.org Protocols * ProtocolTransports ssh </vhost> 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
