(2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/10/2012 8:17 AM, Weijun Wang wrote:
> 
> 
> On 08/10/2012 12:04 AM, Xuelei Fan wrote:
>> The new webrev:
>>    http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.02/
>>
>> Diffs from the previous webrev:
>> 1. changed the method names
>>     setServername->setAccessibleServerName
>>     getServername->getAccessibleServerNames
>>     setServernamePattern->setRecognizableServername
>>     getServernamePatterns->getRecognizableServernames
> 
> s/.etRecognizableServername/.etRecognizableServer*N*ame/
> 
Good!

> I'm glad to see the method names for client and server are different,
> although I'm not sure if the current names are the best. What does
> "accessible" mean here?
I spent a lot of time to look for a word pairing with "Recognizable". I
even thought about to use "Requestable". "Accessible" is not a very good
word, any other suggestion?  "reachable"?

> Also, IMO the old name "pattern" is better.
Properly.

Thanks,
Xuelei

> A
> pattern already means "ServerName*s*" so it seems the setter should be
> setRecognizableServerNames, but then, shall we use
> getRecognizableServerNameses for getter?
> 
> Thanks
> Max
> 
>>
>> 2. behaviors changes:
>>     set/getAccessibleServerName(s) will only make sense in client mode,
>> and set/getRecognizableServername(s) will only make sense in server mode.
>>
>> Have not merge all comments from Sean, will do it tomorrow.
>>
>> Thanks,
>> Xuelei
>>
>>
>> On 8/9/2012 9:57 AM, Xuelei Fan wrote:
>>> Please review the design of JEP 114, TLS Server Name Indication (SNI)
>>> Extension.
>>>
>>> The webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.01/
>>>
>>> The following is a list of typical user cases, and the demo code using
>>> this spec for each case.
>>>
>>>
>>> Typical user cases for client side:
>>>
>>> Case 1: I want to access "www.example.com"
>>>     sslParameters.setServerName("host_name", "www.example.com");
>>>     Set the host name explicit.
>>>
>>>     It is recommend that the client always specify the host name.
>>>
>>> Case 2: The server has some compatibility issues, I do not want
>>> to use server name indication for hostname because of the compatibility
>>> concerns.
>>>     sslParameters.setServerName("host_name", "");
>>>     I will not use server name indication for host_name.
>>>
>>> Case 3: I want to access URL, "https://www.example.com".
>>>     Doing nothing, the provider default behaviors will set the hostname
>>> for me. I don't care about what's the real server name indication.
>>>
>>>     Note that it is the compatible behaviors of JDK 7.
>>>
>>> Case 4: the parameter was previously set to "www.example.com" (see
>>> Case 1), but I want to use the provider default value. I need to remove
>>> the previous set value.
>>>     sslParameters.setServerName("host_name", null);
>>>
>>>
>>>
>>> Typical user cases for application server side:
>>>
>>> Case 1: I want to accept all kind of server name indication
>>>      Doing nothing, the server will ignore the server name indication
>>>
>>> Case 2: I want to deny all server name indication of type host name
>>>      sslParameters.setServerName("hostname", "");
>>>
>>> Case 3: I want to accept all kind of server name indication, but
>>> previously, I have set the server name indication to other values. I
>>> need to reset the value
>>>      sslParameters.setServerName("hostname", null);
>>>
>>> Case 4: I want to accept server name indication of "www.example.com".
>>>     sslParameters.setServerName("host_name", "www.example.com");
>>>
>>> Case 5: I want to accept server name indication of
>>> "www.xuelei.com", but I also have alternative names of "www.example.edu"
>>> and "www.example.org".
>>>     sslParameters.setServerName("host_name", "www.example.com");
>>>     sslParameters.setServernamePattern("host_name",
>>>            Pattern.compile("www\\.example\\.(edu|org)"));
>>>
>>> Case 6: I want to accept server name indication of
>>> "www.example.com", and I have no alternative name. But I need to make
>>> sure that other component does not set alternative name for me in
>>> previous calling.
>>>     sslParameters.setServerName("host_name", "www.example.com");
>>>     sslParameters.setServernamePattern("host_name", null);
>>>
>>>
>>> Typical user cases for dispatch server:
>>> A dispatch server is one server who parsers the server name indication,
>>> and dispatches the connection to the right/real server on a virtual
>>> hosting environment.
>>>
>>> See section 2, "The How-To and Scenarios in Example" of the README:
>>>     http://cr.openjdk.java.net./~xuelei/7068321/README
>>>
>>> I appreciate any feedback about the spec.
>>>
>>> Thanks & Regards,
>>> Xuelei
>>>
>>