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 >
