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.
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.
Thanks,
Brad
[1] http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012183.html
