David, sorry, but I don't understand your proposal.
Can you please write it down in pseudo code what a server application should do and what the JDK should do to negotiate HTTP/2 with a client ? I don't see how it is even possible for a user to decide anything *before* the handshaking is even initiated, like you say. It obviously does not have enough information. This is the current algorithm (A=app code, J=JDK code): A: sslParameters.setApplicationProtocols(H2, H1); A: (optional, only needed for H2) sort ciphers to favor H2 A: start handshake J: receive ClientHello J: ciphers = intersect client/server ciphers J: aps = intersect client/server application protocols J: for each cipher in ciphers J: for each ap in aps J: if (ap.matches(cipher & other info)) break J end // aps [A: ap.matches() calls into application code to return whether ap is good for the given info] J: if (ap was not selected) continue; // to next cipher J: if (trySetCipherSuite(cipher)) break; // success J: end // ciphers J: send ServerHello J: terminate handshake A: sslEngine/sslSocket.getApplicationProtocol() Note that the JDK provides default implementations for H1 and H2 for ap.matches(), but in general these will be implemented by application code. For an application that wants to support H2, this boils down to the first 2 lines, the rest is in the JDK. Thanks ! -- 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
