Hi, On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon <michael.x.mcma...@oracle.com> wrote: > Okay, I see the point you are making. It's more a question of whether > the constraints themselves are appropriate.
And convince the HTTP/2 editors :( > I've another question. In the work you've done so far, did you allow > for the possibility of separate certificates to be selected per ALPN > instance? > > I'm guessing that if multiple applications are to be supported > over one TCP port (client or server) then different certificates might be > needed for each application. Or is that not a reasonable assumption? If I understand you correctly, you are saying that you want a connection with SNI=foo.domain.com to *not* trigger ALPN, but a connection with SNI=bar.domain.com to trigger ALPN ? We don't support this right now in Jetty, but the current ALPN API probably does: at the moment of selecting the protocol, the application can retrieve the SNI and decide what protocol to select. See for example: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-alpn/jetty-alpn-server/src/main/java/org/eclipse/jetty/alpn/server/ALPNServerConnection.java#n49 There you can call getSSLEngine(), which will be able to return a number of information about the handshake (such as the cipher chosen). Makes sense ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
