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

Weijun Wang weijun.wang at oracle.com
Fri Aug 10 00:17:14 UTC 2012

On 08/10/2012 12:04 AM, Xuelei Fan wrote:

The new webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrevspec.02/

Diffs from the previous webrev: 1. changed the method names setServername->setAccessibleServerName getServername->getAccessibleServerNames setServernamePattern->setRecognizableServername getServernamePatterns->getRecognizableServernames

s/.etRecognizableServername/.etRecognizableServerName/

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 "ServerNames" 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/webrevspec.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("hostname", "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("hostname", ""); I will not use server name indication for hostname. 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("hostname", 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("hostname", "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("hostname", "www.example.com"); sslParameters.setServernamePattern("hostname", 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("hostname", "www.example.com"); sslParameters.setServernamePattern("hostname", 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

More information about the security-dev mailing list