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

[Xuelei Fan]

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

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
>