On Thu, 26 Nov 2020 20:26:36 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> Certain TLS ALPN values can't be properly read or written by the SunJSSE >> provider. This is due to the choice of Strings as the API interface and the >> undocumented internal use of the UTF-8 Character Set which converts >> characters larger than U+00007F into multi-byte arrays that may not be >> expected by a peer. >> >> Full details are available in: >> >> - Bug: https://bugs.openjdk.java.net/browse/JDK-8254631 >> - CSR: https://bugs.openjdk.java.net/browse/JDK-8256817 > > src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 341: > >> 339: * The ApplicationProtocol {@code String} values returned by the >> methods in >> 340: * this class are in the network byte representation sent by the peer >> and >> 341: * may need to be converted to its Unicode format before use. For >> example, > > I think there are two possible directions to use the bytes, concerting > application ALPN representation to network byte representation, or concerting > network bytes to application representation. The 1st sentence, I may focus > on the the network byte representation description. > > "The ApplicationProtocol {@code String} values returned by the methods in > this class are in the network byte representation sent by the peer. If an > ALPN value is not encoded in network byte ..., an conversion may be required. > For example, ..." Discussed with Xuelei, the concern was it wasn't clear that you could compare using byte[] or Strings, and possible byte encodings that might be received. I believe these have been addressed in the current version. ------------- PR: https://git.openjdk.java.net/jdk/pull/1440
