Thanks! Xuelei
On 10/3/2015 8:19 AM, 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 >
