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
