Hi, On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore <bradford.wetm...@oracle.com> wrote: > Hi, > > I have just posted the second iteration of the ALPN proposal which hopefully > addresses all of the comments raised here. It is in javadoc format, but > things can certainly be adjusted: > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/ > > Please see the archive [1] for previous design discussion. I will be > writing up usage examples in the next few days. > > The significant changes: > > ExtendedSSLSession > public List<String> getReceivedApplicationProtocols() { > > This will allow applications to examine which protocol names were > sent.
This is a constant once the application protocols are received, so it can be surely retrieved from SSLParameters. I don't understand why it is replicated here ? > SSLParameters > mentions both ALPN/NPN as possible protocols. I removed the > discussion about "server" and "client" since ALPN/NPN essentially > reverse the roles. > > mentions "appropriate character sets" for String-byte[] conversions > such as UTF-8 for ALPN. > > The application protocol selector is now a @FunctionalInterface > (i.e. lambda-ready) called SSLFunction. It is to throw an > SSLException if no values are supported, or null if you want to > treat as an unknown extension. > > Defined constants for HTTP/1.1 and HTTP/2. > > SSLSession > > Called out that getHandshakeSession's ciphersuite may vary until > selected. > > SSLBase > > A new marker interface that SSLEngine/SSLSocket will implement. > This will allow for a single SSLFunction instead of having > SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require > that the lambda do a instanceof, unless we were to move the common > Socket/Engine APIs into this class. I'm not sure about this one being a marker interface. I could understand if it extracted the common functionality of SSLEngine and SSLSocket, but a marker interface does not really add much, and perhaps I would prefer it entirely gone. On the same note, why is SSLFunction generic at all ? Also, it is critical to detail how the mechanism work. Will SSLFunction be invoked multiple times, or only once ? When, exactly, with respect to cipher selection and alias selection ? Example implementations for SSLFunction would be great to have: the typical HTTP/2 case is to select the application protocol based on the TLS protocol and the already negotiated cipher. 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
