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

Xuelei Fan xuelei.fan at oracle.com
Fri Aug 10 00:47:05 UTC 2012

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/webrevspec.02/

Diffs from the previous webrev: 1. changed the method names setServername->setAccessibleServerName getServername->getAccessibleServerNames setServernamePattern->setRecognizableServername getServernamePatterns->getRecognizableServernames s/.etRecognizableServername/.etRecognizableServerName/ 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 "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