On Aug 15, 2012, at 11:05 PM, Weijun Wang <[email protected]> wrote:
>>>
>>>> 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.
>
We have to consider two things, the type and the encoding method of the value.
For oracle provider, we will not support unknown type in SSLParameters because
we don't know the encoding method. We support unknown type in session but we
require the value is encoded in utf-8.
I do not prefer integer for the type because from the integer type I cannot
tell whether the type is unknown or not, and then cannot make sure what is the
proper encoding according. For example, the old application does not know
"nick-name", so the type integer is 1 and the value encoded as UTF-8, but what
if the encoding is not UTF-8 in the formal spec? We will not be able to decode
the value properly.
Xuelei
> Thanks
> Max
>
