On Fri, Jun 5, 2015 at 8:39 AM Stefan Eissing <stefan.eiss...@greenbytes.de> wrote:
> > > 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. > > I think "Protocols" and moving the registration in the patch to the core is a good compromise. If the requirement anyone has interest in working on is h2 over tls, then at the moment the only effect will be driving the ALPN negotiation.
