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

[Weijun Wang]

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/

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? Also, IMO the old name "pattern" is better. 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
>>
>