I didn't reply on this last week, but this looks workable to me. Thanks!
On 10/02/2015 07:19 PM, Bradford Wetmore wrote:
On 10/1/2015 7:35 PM, Xuelei Fan wrote:
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator were
moved to StandardConstants.
2. StandardConstants. Strings for "h2" and "http/1.1" are back. And
now that you are parsing the raw network bytes, I added a convenience
mapping between the two byte ciphersuite IANA-assigned value and the
Java Standard Name.
There is no SSLExplorer in OpenJDK. I think, maybe, the map is not
belong to OpenJDK either.
I think, the constants for HTTP2 is also belong to application protocol
(HTTP2) layer. Application (HTTP2) implementation would take care of
them. Maybe, they are not a part of JSSE framework either.
Ok, I've removed all of the H2 constants from StandardConstants. I've
mentioned to the the H2/network team that this is something they will
need to handle/include (e.g. Blacklist/Comparator) in their code, and
they might want to consider APIs similar to what I had.
I personally found it very useful to have a proper mapping to get the
SSL_ vs. TLS_ prefix correct in the blacklist.
I would like to have "h2" and "http/1.1" defined as Standard Algorithms
Docs as we usually did for other standard constants.
Of course, they will be added as Standard Algorithm names.
3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even
though these could go into SSLParameters, this change makes backporting
much easier. The helper code simply has to reflectively look for the
four methods in the implementation classes, and call if they are there.
Otherwise, there would have to be reflection both in the user code
(above) and implementation (to see if the passed SSLParameters had the
new methods via a subclass).
But, looking forward, per JSSE framework, SSLParameters should be the
central place to define SSL/TLS configuration parameters. We'd better
follow the conventions so that application developers won't get confused
about where SSL/TLS parameters should be configured.
I went back and forth on this many, many times yesterday.
Maybe, we cannot add public APIs for backporting.
I figured we'd have to use reflection on user-derived classes to see if
the methods were there, but apparently implementation-specifc APIs can
be added in an update release, just not Java APIs. So if we really can
do that, then we can add a jdk.SSLParameters/
org.openjdk.jsse.SSLParameters extends SSLParameters, and in the
implementation, look for instanceof.
I think backporting is
another history, and would better not impact too much of the design for
JDK 9 and future releases.
Ok, so get/setApplicationProtocols() is back in SSLParameters.
Thanks for the comments everyone. I'm submitting the following to the
CCC (internal review board):
http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/
Changes:
1. No H2 Blacklist/Comparator
2. set/getApplicationProtocols() back to SSLParameters.
Thanks,
Brad
--
- DML
