On Wed, 25 Nov 2020 20:03:01 GMT, Bradford Wetmore <wetm...@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, ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/1440
