4. I just noticed that the type can be also "sni-<n>". What if someone
call setServerName("sni-0", "...")? Is it the same as calling
setServerName(SNI_HOST_NAME, "...")?
Unspecified behavior. Maybe not, because of the value encoding method.
We may throw exception in Oracle provider. Other providers may want to
support "sni-32" or "principal" for its private server name type.
I'm not sure. Suppose tomorrow the type nick_name(1) is supported and a
customer begins using "sni-1". The day after tomorrow, Java is updated
and we have a string "nick_name" for it. I guess you will make "sni-1"
and "nick_home" equivalent so that the customer's app will still work?
If so, why not start doing it today for "sni-0" and "host_name"?
In fact, I don't quite understand how this is used. On the client side,
when the developer knows nick_name(1) is not yet supported by the
current JDK, he will use the "sni-1" type so that the SNI will be
correctly encoded. Then, JDK is updated and the name type is now
"nick_name", but I believe the old app should still work, so "sni-1"
should be still accepted and be equivalent to "nick_name".
On the server side, the old JDK and new JDK would return different
values for getServerNames(). It's likely that the user app will be
broken if it cannot successfully predict the "nick_name" name and
already support it.
Therefore, seriously, I suggest we change Map<String,String> to
Map<Integer,String>. Since we already defined SSLParamters constant for
the types, the user won't feel uncomfortable.
Thanks
Max
